Překlad DNS záznamu mailserveru Office365

[M Z]

Zdravim,
na mailserveru mame nastavenou kontrolu A a PTR zaznamu odesilajicich mailserveru. Mel jsme nekolik stiznosti o problemech s dorucovanim mailu od lidi z office365.

V logu jsem nasel, ze se obcas, nebo spis docela casto, nepodari prelozit IP adresu na A zaznam, ale take casto A zaznam na IP, takze server mail odmitne prijmout. Samozrejme jsem nejdrive podeziral nase DNS servery, ale ted to spis vypada na obecny problem.

Zkuste napr. mail-eopbgr80139.outbound.protection.outlook.com  v dnschecker.org. Nevim jak moc je na dnschecker spolehnuti, ale vsechny ostatni adresy, ktere jsem zkousel, byly 100% OK.
Napada me, ze by to mohlo byt nastaveni refresh a retry v SOA zanamu domeny outlook.com:

Kód: [Vybrat]

outlook.com. 60 IN SOA sn6mgt0101dc003.prdmgt01.prod.exchangelabs.com. msnhst.microsoft.com. (
2014984616 ; serial
300        ; refresh (5 minutes)
900        ; retry (15 minutes)
2419200    ; expire (4 weeks)
60         ; minimum (1 minute)

Nemelo by byt retry vzdy mensi nez refresh? A napada nekoho co s tim?

[Reklama]

[McFly]

Poslední dny v logu pozoruji to samé.

Server nedokáže přeložit IP adresu na reverzní záznam a pošta je díky tomu dočasně odmítnutá (návratový kód 450). Týká se to jen a pouze serverů outlook.com (Office365). Díky tomu dochází ke zdržení pošty.

Kód: [Vybrat]

Aug 26 00:09:27 mail postfix/smtpd[22812]: NOQUEUE: reject: RCPT from unknown[40.107.22.82]: 450 4.7.1 Client host rejected: cannot find your hostname, [40.107.22.82]; from=<*> to=<*> proto=ESMTP helo=<EUR05-AM6-obe.outbound.protection.outlook.com>

Aug 26 01:09:52 mail postfix/smtpd[26738]: connect from mail-eopbgr10052.outbound.protection.outlook.com[40.107.1.52]
Aug 26 01:09:52 mail postfix/smtpd[26738]: Anonymous TLS connection established from mail-eopbgr10052.outbound.protection.outlook.com[40.107.1.52]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

[McFly]

Jen doplním, že na serveru běží vlastní DNS, žádný není nadřazený (kvůli kontrolám blacklistů), takže přímý překlad...

[M Z]

Tak vzhledem k tomu ze problem s tim ma i Google (8.8.8.8 ) a Cesnet (195.113.144.194) DNS, nevidel bych to na nejaky problem s lokalni DNS konfiguraci. U nas je to horsi protoze Ironport to odmitne s 5.x.x kodem, takze mail se nedoruci.

[RDa]

WAR: muzete si zgrepnout dosavadni logy a nalezene C site si whitelistovat (treba i jen pro stav, kdy dns zrovna nejede)

[Reklama]

[McFly]

WAR: muzete si zgrepnout dosavadni logy a nalezene C site si whitelistovat (treba i jen pro stav, kdy dns zrovna nejede)

To jsem zkoušel - našel jsem si celý /14 a /13 IP rozsah MS, který v logu vidím. Pokud jsem zakázal kontrolu PTR u tohoto rozsahu, posunul jsem se o kousek dál, ale končil jsem na kontrole HELO hostname, protože DNS prostě nic nepřeloží. Pokud bych povolil i HELO kontrolu (teoreticky to jde, nezkoušel jsem), otázka je, jaké skóre by přiřadil SpamAssassin, když by nebyly dostupné DNS záznamy pro PTR, SPF, DKIM, DMARC... ale mohl bych to zkusit.

M Z: A nelze to v Ironportu změnit? V Postfixu to lze nakonfigurovat.

[M Z]

Jasne ze to jde, musel jsem to vypnout ;-). Spis me prekvapuje, ze jsem nenasel na netu, ze by  si na to nekdo stezoval. Vzdyt to musi delat problem spouste antispam reseni.

[McFly]

Já bych to možná nevypínal, jen změnil návratový kód z 5xx na 450 (dočasně odmítnuto). Tak to má Postfix standardně, takže takový mail se jen zpozdí - obvykle jej doručí jiný server Outlook.com, u kterého ty PTR záznamy v tu chvíli přeložit jdou.

Btw co ostatní správci poštovních řešení/serverů, nedělá vám stejně jako mně a MZ poslední dobou problém příjem pošty z Outlook.com (aka Office365)? V logu se to dá najít třeba takto:

Kód: [Vybrat]

cat maillog | grep "outlook.com" | grep rejected


[McFly]

Tak mi to nedalo a začal jsem pátrat dál. Nasbíral jsem data (pcap) a ta analyzoval ve Wiresharku, viz příloha.

Nevíte, zda existuje někdo, s kým se dá pobavit a reportovat jim to? :/ Někdo z Azure?

[McFly]

Když tak mne opravte, ale jak to chápu já, vybraný NS 104.47.44.8 (na obrázku dole) by měl být pro doménu autoritativní, ale není, proto z něj nepřijde žádná relevantní odpověď (v odpovědi chybí info o A záznamu). NS 104.47.124.8 (na obrázku nahoře) je autoritativní a vše je tudíž v pořádku, očekávaná odpověď dorazila. A díky striktním kontrolám v Postfixu (ze kterých nechci ustoupit, protože je to kladivo na spammery) se e-mail dočasně odmítne, protože má problém s PTR/A záznamem. Obdobnou kontrolu měl i kolega s Ironportem.

Zřejmě mnoho poštovních systémů žádné problémy nezaznamená, pokud tam neběží podobné kontroly a správce si s tím nepohrál nebo na to peče. Pro mne je to jednoznačně chyba na straně MS...

Zkoušel jsem poslat report na domains@microsoft.com a taky na msnhst@microsoft.com, ale pochybuju, že to někdo bude číst (adresy jsem vyčetl z whois). Taky jsem chtěl položit dotaz/připomínku na TechNet MS, ale když jsem si založil účet a přihlásil se, dostala mne do kolen hláška "Pokud chcete položit otázku, musíte profil používat více než 30 dnů", což mne dokonale odradilo se tím nadále zabývat... A když se někdo ozve, proč mu přišel e-mail z Office365 až po 365 minutách, mohu jej směle odkázat na tohle vlákno.

[McFly]

Ještě mne napadl malý workaround (pro BIND), co se mi moc nelíbí (je třeba kontrolovat, že to stále funguje):

Kód: [Vybrat]

// funkcni otestovane autoritativni servery
zone "outlook.com" IN {
        type forward;
        forwarders { 104.47.124.8; 104.47.38.8; };
};

[McFly]

Tak po více jak dvou týdnech ostrého provozu musím říci, že vytvoření zóny outlook.com v BINDu funguje, už žádná pozdržená pošta a resolving maká.

Kód: [Vybrat]

zone "outlook.com" IN {
        type forward;
        forwarders { 104.47.124.8; 104.47.38.8; 104.47.40.8; };
};