Sendmail: dirección del remitente rechazada (dominio no encontrado)

11

Tengo problemas con el envío de correo en nuestro servidor web. Algunos correos se envían y entregan sin problemas (por ejemplo, Gmail), mientras que otros se aplazan con "Dirección del remitente rechazada: dominio no encontrado"

Entiendo que esta es una medida de protección contra spam mediante la cual se realiza una búsqueda en el dominio de envío, pero nuestro dominio tiene registros MX:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
premiumconnect.co.za    mail exchanger = 10 za-smtp-2.mimecast.co.za.
premiumconnect.co.za    mail exchanger = 10 za-smtp-1.mimecast.co.za.

Authoritative answers can be found from:

(Además, ¿por qué no tenemos respuestas autorizadas? ¿Podría ser ese el problema?)

Además de un registro A:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   premiumconnect.co.za
Address: 196.28.97.202

Aquí están los registros de un correo específico que intentaba enviarse:

Feb  5 12:07:52 premiumconnect sm-mta[2411]: s15C7qYp002411: from=<[email protected]>, size=3522, class=0, nrcpts=1, msgid=<[email protected]>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Feb  5 12:07:52 premiumconnect sendmail[2410]: s15C7q0o002410: to=*****@tott.co.za, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=33324, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (s15C7qYp002411 Message accepted for delivery)
Feb  5 12:07:52 premiumconnect sm-mta[2413]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=123522, relay=antispam-vdc-01.gam.co.za. [41.0.5.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found
Feb  5 12:07:53 premiumconnect sm-mta[2413]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=123522, relay=mx-filter-01.gam.co.za. [41.0.5.131], dsn=4.1.8, stat=Deferred: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found
Feb  5 12:12:46 premiumconnect sm-mta[2479]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:04:54, xdelay=00:00:00, mailer=esmtp, pri=213522, relay=mx-filter-01.gam.co.za. [41.0.5.131], dsn=4.1.8, stat=Deferred: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found
Feb  5 12:12:46 premiumconnect sm-mta[2479]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:04:54, xdelay=00:00:00, mailer=esmtp, pri=213522, relay=antispam-vdc-01.gam.co.za. [41.0.5.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found

Tengo poca experiencia con Sendmail (o MTA en general), no estoy seguro de qué otra información podría ser útil.

email sendmail spam email-server JonoCoetzee
fuente
Si no está dando respuestas autorizadas, debe asegurarse de que su registrador de dominios tenga sus servidores NS listados ...
NickW
Nuestro registrador de dominios nos obliga a usar sus servidores de nombres, desafortunadamente no podría cambiar si quisiera ...
JonoCoetzee
Bueno, si se ve obligado a usar el suyo, debe asegurarse de que sus servidores NS estén devolviendo los registros que USTED desea, y eso incluye un registro MX adecuado. Asegúrese también de que su ISP o su empresa de alojamiento publiquen un registro RDNS adecuado para su servidor de correo.
NickW
De acuerdo, los registros devueltos anteriormente son correctos para nuestro dominio y lo que se establece en el NS autorizado (en el registrador), incluido el registro MX que apunta a un servidor de correo externo. Además, el servidor de correo (definido en el registro MX) se resuelve con una búsqueda inversa de DNS. Sin embargo, el dominio / servidor web no lo hace, ¿no está seguro de si esto afectaría las cosas?
JonoCoetzee
Entonces, ¿sus servidores web están transmitiendo a través de su servidor de correo? Esa sería la forma más sencilla de garantizar que el correo que envían se enviará ..
NickW 05 de

Respuestas:

8

Este error se refiere específicamente a la dirección 'de', no al servidor de correo remitente. Como tal, los registros MX no son relevantes, y su configuración de MTA probablemente no sea relevante.

El problema es que está enviando un correo electrónico desde "[email protected]", que el destinatario determina correctamente que no puede ser una dirección de correo electrónico válida, ya que el dominio debian70.vm no existe.

La solución dependerá de cómo está generando exactamente estos correos electrónicos. Una opción es especificar la dirección 'desde' deseada en cualquier software que esté generando estos correos.

Por otro lado, parece que no está especificando activamente una dirección 'desde', sino que permite que el sistema genere una. En ese caso, la parte posterior a @ se establece en función de lo que el sistema cree que es su nombre de correo. Debian comprueba '/ etc / mailname' para determinar esto, y si no encuentra nada, utiliza su nombre de dominio completo, que en su caso es 'debian70.vm', un nombre que solo es válido para su red interna desde está en el dominio de nivel superior .vm.

Si edita / etc / mailname (creándolo si es necesario) para decir 'premiumconnect.co.za' (sin las comillas), probablemente resolverá su problema.

De lo contrario, eso podría indicar que un MTA está generando la dirección basada en alguna otra configuración, por lo que necesitaríamos saber más sobre la configuración de su MTA.

Nye
fuente
Entiendo que, si nos fijamos en la primera línea del registro verá que el que desde la dirección se establece: from=<[email protected]>. Ya he intentado configurar / etc / mailname. ¿Qué haría que esto no funcione?
JonoCoetzee
¿Probé nuevamente con Gmail y los correos electrónicos siguen apareciendo como [email protected]? He reiniciado el servicio sendmail pero no hay cambios.
JonoCoetzee
Tengo Authentication-Warning: premiumconnect.co.za: www-data set sender to [email protected] using -fen el mail.log, ¿podría estar relacionado?
JonoCoetzee
2

¿Cómo se supone que debe resolver el dominio debian70.vm? me parece que estás usando [email protected] como la dirección del remitente. La verificación de spam se realiza a través de debian70.vm, que no se puede resolver.

drogado
fuente
@slm Nope. Esa es en realidad la respuesta en mi humilde opinión. Para mí, está tratando de enviar correos como [email protected], cuyo dominio no puede ser resuelto por el servidor remoto. Lo siento si no está claro, modificaré mi respuesta.
drogado
Empedrado es correcto, que es el principal problema .. una secundaria podría ser la razón por su servidor de retransmisión está aceptando las direcciones de esa manera :)
NickW
@stoned: la edición lo mejora, eliminé el comentario, gracias.
slm
@NickW en realidad me parece que está usando la máquina local (127.0.0.1) para enviar el correo, por lo que funciona. Supongo que no transmitió el correo a ninguna parte, o de lo contrario probablemente recibiría un correo fallido en lugar de un registro de errores. Si eso es cierto, tendrá problemas con los verificadores de spam como SpamAssassin, pero por lo general no recibirá ningún comentario al respecto: el servidor de correo del destinatario simplemente descartará el mensaje.
drogado
Estoy de acuerdo, que es la razón detrás de mi último comentario bajo su pregunta :)
NickW
1

Encontré el problema, una vez que las otras respuestas me señalaron en la dirección correcta. El sendmail.mc (autogenerado) tenía una línea MASQUERADE_AS(`debian70.vm')dnl, cambié esto MASQUERADE_AS(`premiumconnect.co.za')dnly los correos electrónicos se están configurando correctamente ahora. Gracias por la perspicacia.

JonoCoetzee
fuente