Sendmail: adresse de l'expéditeur rejetée (domaine introuvable)

11

Je rencontre des problèmes avec l'envoi de courrier sur notre serveur Web. Certains courriers sont envoyés et livrés sans aucun problème (par exemple Gmail), tandis que d'autres sont différés avec "Adresse d'expéditeur rejetée: domaine introuvable"

Je comprends qu'il s'agit d'une mesure de protection anti-spam par laquelle une recherche est effectuée sur le domaine d'envoi, mais notre domaine a des enregistrements 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:

(En passant, pourquoi n'avons-nous pas de réponses faisant autorité? Cela pourrait-il être le problème?)

Ainsi qu'un enregistrement A:

Server:     8.8.8.8
Address:    8.8.8.8#53

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

Voici les journaux d'un courrier spécifique qui tentait d'être envoyé:

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

J'ai peu d'expérience avec Sendmail (ou les MTA en général), je ne sais pas quelles autres informations pourraient être utiles.

email sendmail spam email-server JonoCoetzee
la source
Si vous ne donnez pas de réponses faisant autorité, vous devez vous assurer que votre registraire de domaine a vos serveurs NS répertoriés.
NickW
Notre registraire de domaine nous oblige à utiliser leurs serveurs de noms, ne pouvait pas changer si je le voulais malheureusement ...
JonoCoetzee
Eh bien, si vous êtes obligé d'utiliser les leurs, vous devez vous assurer que leurs serveurs NS retournent les enregistrements que vous voulez, et cela inclut un enregistrement MX approprié. Assurez-vous également que votre FAI ou votre hébergeur publie un enregistrement RDNS approprié pour votre serveur de messagerie.
NickW
D'accord, les enregistrements renvoyés ci-dessus sont corrects pour notre domaine et ce qui est défini dans le NS faisant autorité (au bureau d'enregistrement), y compris l'enregistrement MX qui pointe vers un serveur de messagerie externe. Le serveur de messagerie (défini dans l'enregistrement MX) se résout également par une recherche DNS inversée. Cependant, le domaine / serveur Web ne sait pas si cela affecterait les choses?
JonoCoetzee
Alors, vos serveurs Web relaient-ils via votre serveur de messagerie? Ce serait le moyen le plus simple de s'assurer que le courrier qu'ils envoient sera
acheminé

Réponses:

8

Cette erreur concerne spécifiquement l'adresse «de», pas le serveur de messagerie expéditeur. En tant que tels, les enregistrements MX ne sont pas pertinents et vos paramètres MTA ne sont probablement pas pertinents.

Le problème est que vous envoyez un e-mail à partir de "[email protected]", que le destinataire détermine correctement ne peut pas être une adresse e-mail valide, car le domaine debian70.vm n'existe pas.

La solution dépendra de la façon dont vous générez exactement ces e-mails. Une option consiste à spécifier l'adresse «de» souhaitée dans le logiciel qui génère ces messages.

D'un autre côté, il semble que vous ne spécifiez pas activement une adresse de provenance, mais que vous laissez le système en générer une. Dans ce cas, la partie après le @ est définie en fonction de ce que le système pense être son nom de messagerie. Debian vérifie '/ etc / mailname' pour le déterminer, et s'il ne trouve rien, il utilise son nom de domaine complet, qui dans votre cas est 'debian70.vm' - un nom qui n'est valable que pour votre réseau interne depuis c'est dans le domaine de premier niveau .vm.

Si vous modifiez / etc / mailname (en le créant si nécessaire) pour dire 'premiumconnect.co.za' (sans les guillemets), cela résoudra probablement votre problème.

Sinon, cela pourrait indiquer qu'un MTA génère l'adresse en fonction d'une autre configuration, nous aurions donc besoin d'en savoir plus sur votre configuration MTA.

Nye
la source
Je reçois que, si vous regardez la première ligne dans le journal , vous verrez que le de l' adresse est définie: from=<[email protected]>. J'ai déjà essayé de configurer / etc / mailname. Qu'est-ce qui empêcherait cela de fonctionner?
JonoCoetzee
J'ai testé à nouveau avec Gmail et les e-mails continuent de passer par [email protected]? J'ai redémarré le service sendmail mais aucun changement.
JonoCoetzee
J'ai Authentication-Warning: premiumconnect.co.za: www-data set sender to [email protected] using -fdans le mail.log, cela pourrait-il être lié?
JonoCoetzee
2

Comment est-il censé résoudre le domaine debian70.vm? me semble que vous utilisez [email protected] comme adresse d'expéditeur. La vérification du spam se fait sur debian70.vm, qui ne peut pas être résolu.

lapidé
la source
@slm Nope. C'est en fait la réponse à mon humble avis. Pour moi, il essaie d'envoyer du courrier en tant que [email protected], dont le domaine ne peut pas être résolu par le serveur distant. Désolé si ce n'est pas clair, je vais modifier ma réponse.
lapidé le
lapidé a raison, c'est le principal problème .. un problème secondaire pourrait être la raison pour laquelle son serveur relais accepte des adresses comme ça :)
NickW
@ étonné - la modification le rend meilleur, j'ai supprimé le commentaire, merci.
slm
@NickW il me semble qu'il utilise la machine locale (127.0.0.1) pour envoyer le courrier, donc ça marche. Je suppose qu'il n'a relayé le courrier nulle part, sinon il obtiendrait probablement un courrier d'échec plutôt qu'un journal d'erreurs. Si c'est vrai, il rencontrera des problèmes avec les vérificateurs de spam comme SpamAssassin, mais il ne recevra généralement aucun commentaire à ce sujet - le message sera simplement rejeté par le serveur de messagerie du destinataire.
lapidé le
Je suis d'accord, ce qui est la raison de mon dernier commentaire sous sa question :)
NickW
1

J'ai trouvé le problème, une fois que j'ai été pointé dans la bonne direction par les autres réponses. Le sendmail.mc (généré automatiquement) avait une ligne MASQUERADE_AS(`debian70.vm')dnl, j'ai changé cela en MASQUERADE_AS(`premiumconnect.co.za')dnlet les e-mails sont définis correctement maintenant. Merci pour la perspicacité.

JonoCoetzee
la source