Sendmail: odrzucono adres nadawcy (nie znaleziono domeny)

Mam problemy z wysyłaniem poczty na naszym serwerze internetowym. Niektóre e-maile są wysyłane i dostarczane bez żadnych problemów (np. Gmail), a inne są odraczane z „Odrzucono adres nadawcy: Nie znaleziono domeny”

Rozumiem, że jest to środek ochrony przed spamem, dzięki któremu wyszukiwanie odbywa się w domenie wysyłającej, ale nasza domena ma rekordy 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:

(Nawiasem mówiąc, dlaczego nie mamy wiarygodnych odpowiedzi? Czy to może być problem?)

A także rekord A:

Server:     8.8.8.8
Address:    8.8.8.8#53

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

Oto dzienniki dla określonej poczty, która próbowała zostać wysłana:

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

Mam niewielkie doświadczenie z Sendmailem (lub ogólnie MTA), nie jestem pewien, jakie inne informacje mogą być przydatne.

— JonoCoetzee
źródło

Jeśli nie udzielasz autorytatywnych odpowiedzi, musisz upewnić się, że rejestrator domeny ma na liście Twoje serwery NS.

— NickW

Nasz rejestrator domen zmusza nas do korzystania z serwerów nazw, nie mógłbym tego zmienić, gdybym chciał niestety ...

— JonoCoetzee

Cóż, jeśli jesteś zmuszony do korzystania z nich, musisz upewnić się, że ich serwery NS zwracają rekordy, które chcesz, i że zawierają odpowiedni rekord MX. Upewnij się również, że Twój dostawca usług internetowych lub firma hostingowa opublikuje odpowiedni rekord RDNS dla twojego serwera pocztowego.

— NickW

Okay, rekordy zwrócone powyżej są prawidłowe dla naszej domeny i tego, co jest ustawione w autorytatywnym NS (u rejestratora), w tym rekordu MX, który wskazuje na zewnętrzny serwer pocztowy. Serwer poczty (zdefiniowany w rekordzie MX) rozwiązuje problem za pomocą wstecznego wyszukiwania DNS. Domena / serwer sieciowy nie, ale nie jesteś pewien, czy to wpłynie na różne rzeczy?

— JonoCoetzee

Więc czy twoje serwery WWW przekazują za pośrednictwem twojego serwera pocztowego? Byłby to najprostszy sposób, aby upewnić się, że poczta, którą wysyłają, przejdzie ..

— NickW

Odpowiedzi:

Ten błąd dotyczy w szczególności adresu „od”, a nie serwera poczty wysyłającej. W związku z tym rekordy MX nie są istotne, a ustawienia MTA prawdopodobnie nie są istotne.

Problem polega na tym, że wysyłasz wiadomość e-mail z adresu „bookings@debian70.vm”, który odbiorca poprawnie stwierdził, że nie może być prawidłowym adresem e-mail, ponieważ domena debian70.vm nie istnieje.

Rozwiązanie będzie zależeć od tego, jak dokładnie generujesz te e-maile. Jedną z opcji jest określenie pożądanego adresu „z” w dowolnym oprogramowaniu generującym te wiadomości.

Z drugiej strony wygląda na to, że nie określasz aktywnie adresu „od”, ale pozwalasz systemowi go wygenerować. W takim przypadku część po znaku @ jest ustawiana na podstawie tego, co system uważa za swoją nazwę poczty. Debian sprawdza „/ etc / mailname”, aby to ustalić, a jeśli niczego nie znajdzie, używa swojej w pełni kwalifikowanej nazwy domeny, która w twoim przypadku to „debian70.vm” - nazwa, która jest ważna tylko dla twojej sieci wewnętrznej od jest w domenie najwyższego poziomu .vm.

Jeśli edytujesz / etc / mailname (tworząc go w razie potrzeby), aby powiedzieć „premiumconnect.co.za” (bez cudzysłowów), prawdopodobnie rozwiąże to twój problem.

Jeśli nie, może to oznaczać, że MTA generuje adres na podstawie innej konfiguracji, więc będziemy musieli dowiedzieć się więcej o konfiguracji MTA.

— Nie
źródło

Rozumiem to, jeśli spojrzeć na pierwszej linii w dzienniku zobaczysz że że od adresu jest ustawiony: from=<bookings@premiumconnect.co.za>. Próbowałem już ustawić / etc / mailname. Co może spowodować, że to nie zadziała?

— JonoCoetzee

Testowałem ponownie z Gmailem, a e-maile wciąż są wysyłane jako bookings@debian70.vm? Zrestartowałem usługę sendmail, ale bez zmian.

— JonoCoetzee

Mam Authentication-Warning: premiumconnect.co.za: www-data set sender to bookings@premiumconnect.co.za using -fw mail.log, czy może to być powiązane?

— JonoCoetzee

Jak ma rozwiązać domenę debian70.vm? wygląda na to, że używasz bookings@debian70.vm jako adresu nadawcy. Sprawdzanie spamu odbywa się w pliku debian70.vm, którego nie można rozwiązać.

— zjarany
źródło

@slm Nope. To właściwie odpowiedź imho. Dla mnie próbuje wysłać pocztę jako bookings@debian70.vm, której domeny nie można rozwiązać przez zdalny serwer. Przepraszam, jeśli nie jest jasne, zmienię moją odpowiedź.

— ukamienowany

stoned ma rację, to jest główny problem .. drugorzędny może być powód, dla którego jego serwer przekaźnikowy akceptuje takie adresy :)

— NickW

@stoned - edycja poprawia, usunąłem komentarz, dzięki.

— slm

@NickW wydaje mi się, że używa on lokalnego komputera (127.0.0.1) do wysyłania poczty, więc działa. Wydaje mi się, że nigdzie nie przekazywał poczty, bo inaczej prawdopodobnie dostałby wiadomość o awarii zamiast dziennika błędów. Jeśli to prawda, będzie miał problemy z modułami sprawdzającymi spam, takimi jak SpamAssassin, ale zwykle nie otrzyma za to żadnej informacji zwrotnej - wiadomość zostanie po prostu odrzucona przez serwer pocztowy odbiorcy.

— ukamienowany

Zgadzam się, co jest przyczyną mojego ostatniego komentarza pod jego pytaniem :)

— NickW

Znalazłem problem, gdy inne odpowiedzi wskazały mi właściwy kierunek. (Automatycznie generowany) sendmail.mc miał wiersz MASQUERADE_AS(`debian70.vm')dnl, zmieniłem go na MASQUERADE_AS(`premiumconnect.co.za')dnli e-maile są teraz ustawione poprawnie. Dzięki za wgląd.

— JonoCoetzee
źródło