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

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=<bookings@premiumconnect.co.za>, size=3522, class=0, nrcpts=1, msgid=<52f22998c2680@premiumconnect.co.za>, 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 <bookings@debian70.vm>: 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 <bookings@debian70.vm>: 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 <bookings@debian70.vm>: 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 <bookings@debian70.vm>: 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.

— JonoCoetzee
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:

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 "bookings@debian70.vm", 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
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=<bookings@premiumconnect.co.za>. 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 bookings@debian70.vm? J'ai redémarré le service sendmail mais aucun changement.

— JonoCoetzee

J'ai Authentication-Warning: premiumconnect.co.za: www-data set sender to bookings@premiumconnect.co.za using -fdans le mail.log, cela pourrait-il être lié?

— JonoCoetzee

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

— lapidé
source

@slm Nope. C'est en fait la réponse à mon humble avis. Pour moi, il essaie d'envoyer du courrier en tant que bookings@debian70.vm, 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

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
source