Postfix parece ignorar los registros MX del dominio

Postfix parece ignorar los registros MX del dominio

En mi servidor dedicado, tengo instalado Postfix para enviar correos electrónicos a través de sitios web. Uno de mis clientes aloja su correo electrónico en un tercero, por lo que tenemos registros MX configurados en el dominio.

Sin embargo, al enviar correos electrónicos de Postfix desde el servidor, no reciben los correos electrónicos. Creo que como el dominio apunta al servidor mismo, intenta enviarse correo a sí mismo, pero no hay nada en el servidor para manejar el correo electrónico de ese dominio. (Hay cuentas de correo para otros dominios que funcionan bien).

¿Cómo consigo que Postfix utilice los registros MX del dominio para enviar correo electrónico?El servidor es Ubuntu 8.10 con pila LAMP estándar. Tengo instalado Webmin y un panel de control llamado "Matrix" proporcionado por el host.

EDITAR: si intento enviar un correo electrónico desde mi propia dirección, recibo un correo electrónico de error del sistema de entrega de correo, con este error:

<[email protected]>: user unknown. Command output: Invalid user specified.

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Diagnostic-Code: x-unix; Invalid user specified.

Aquí están las entradas de registro realizadas:

Jan  6 18:06:52 localhost postfix/pickup[29006]: 0329D3F69: uid=33 from=<[email protected]>
Jan  6 18:06:52 localhost postfix/cleanup[30495]: 0329D3F69: message-id=<[email protected]>
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 0329D3F69: from=<[email protected]>, size=611, nrcpt=2 (queue active)
Jan  6 18:06:52 localhost postfix/pipe[30497]: 0329D3F69: to=<[email protected]>, relay=maildrop, delay=0.15, delays=0.1/0/0/0.04, dsn=5.1.1, status=bounced (user unknown. Command output: Invalid user specified. )
Jan  6 18:06:52 localhost postfix/smtp[30498]: 0329D3F69: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[209.85.227.27]:25, delay=0.61, delays=0.1/0.01/0.06/0.45, dsn=2.0.0, status=sent (250 2.0.0 OK 1294337212 o18si30528441wbo.103)
Jan  6 18:06:52 localhost postfix/cleanup[30495]: 868723F75: message-id=<[email protected]>
Jan  6 18:06:52 localhost postfix/bounce[30500]: 0329D3F69: sender non-delivery notification: 868723F75
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 868723F75: from=<>, size=2553, nrcpt=1 (queue active)
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 0329D3F69: removed
Jan  6 18:06:52 localhost postfix/pipe[30497]: 868723F75: to=<[email protected]>, relay=maildrop, delay=0.06, delays=0.01/0/0/0.05, dsn=2.0.0, status=sent (delivered via maildrop service)
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 868723F75: removed

Respuesta1

Estoy aburrido en el trabajo y pensé en mencionar lo siguiente. Nunca he usado este sitio antes, así que perdóname.

A una de las respuestas, comentaste después decir:

"OK, tengo virtual_mailbox_domains = $transport_maps y transport_maps = hash:/etc/postfix/transport. Dentro de ese archivo hay una línea que dice condorproperties.co.uk maildrop: - ¿Debería eliminar esa línea? – DisgruntledGoat ayer"

luego lo siguió con:

"@Devdas: Intenté eliminar esa línea y reiniciar Postfix, no soluciona el problema, ¿tengo que cambiar "maildrop" por algo más? – DisgruntledGoat ayer"

La respuesta a su primera pregunta es "sí". Esa línea en /etc/postfix/transport estaba forzando la entrega de correo local (a través de maildrop) para el correo electrónico destinado a condorproperties.co.uk. Quitarlo es lo más apropiado. El problema es que simplemente reiniciar postfix no es suficiente para aplicar el cambio.

El problema es que el mapa configurado en el archivo de configuración es un hash:/etc/postfix/transport. El archivo, /etc/postfix/transport es la versión legible por humanos del archivo y también debe tener un archivo /etc/postfix/transport.db correspondiente, el mapa hash compilado. Utilice el comando postmap para compilar la versión legible por humanos en la versión hash. Postfix verifica los tiempos de modificación y debería quejarse en voz alta en sus archivos de registro de que /etc/postfix/transport.db está desactualizado. Todo lo que necesita hacer es ejecutar postmap /etc/postfix/transport para que el cambio que realizó antes (eliminando la línea con condorproperties.co.uk) surta efecto. De hecho, no creo que tengas que recargar postfix para que el cambio se active una vez que hayas emitido el comando postmap, pero no estaría de más.

En pocas palabras, ejecute postmap /etc/postfix/transport y luego recargue postfix.

Salud.

Por cierto, la gran pista en sus archivos de registro fue esta línea: 6 de enero 18:06:52 localhost postfix/pipe[30497]: 0329D3F69: to=, relé=maildrop, retraso=0.15, retrasos=0.1/0/0/0.04, dsn=5.1.1, estado=rebotado (usuario desconocido. Salida del comando: usuario especificado no válido).

Observe, a mitad de camino, donde dice retransmisión = envío de correo.

Respuesta2

¿Puedes pegar postconf -n aquí?

Apuesto a que tiene mydomain.co.uk listado explícitamente en uno de mydestination, virtual_mailbox_domains o Relay_domains con un transporte de maildrop.

ring0 tiene la idea correcta, pero ha analizado la pregunta incorrectamente, según tengo entendido. El objetivo es conseguir que el correo electrónico de uno de los dominios del servidor vaya a otra parte, pero permanece en Postfix.

Cualquier servidor de correo tendrá una configuración local que anulará el DNS. Entonces, si su MTA no busca DNS, tiene el dominio en su configuración local.

Respuesta3

postfixsigue los estándares y realiza la resolución de entradas MX de un nombre de dominio, para saber con qué servidor contactar a continuación para transmitir el correo.

  • Es posible que tenga un problema debido al TTL de un nombre de dominio (zona), por ejemplo, actualizó las entradas MX en su registrador, pero el TTL de ese dominio hace que la entrada previamente resuelta permanezca en la caché del servidor de nombres de dominio.

  • Además, es posible que los nombres de dominio en el servidor de destino no se declaren comolocal, haciendo que el servidor rechace los correos (ver los registros, por ejemplo /var/log/mail.log), considerando que su servidor de envío está intentando retransmitir (spam) a través de ese servidor de destino ( mydestinationen /etc/postfix/main.cf).

Intente dig +nocmd mydomain.tld mx +noall +answertener información fácilmente legible, incluido TTL, de los dominios que le preocupan.

Respuesta4

También verifique que no tenga ningún transporte personalizado o mapa de transporte definido de alguna manera para el dominio remoto al que desea enviar correo.

información relacionada