[Megoldva] O365 smtp NDR PTR rekord miatt

Web, mail, IRC, IM, hálózatok

Sziasztok!

Ügyviteli rendszerünk egy O365 postaládán keresztül küldi ki a számláinkat smtp kapcsolaton keresztül. Mostanában furcsa módon egyik levél megérkezett másik nem az ügyfeleknek. Az NDR ben "Misconfigured PTR record" üzenet jelenik meg. Az ügyfél smtp-je SPAM ként visszautasítja. 

Mi ilyenkor a teendő?

  • 530 megtekintés

( n.balazs v | 2020. 05. 05., k – 18:55 )

Szerintem a hibaüzenet egyértelmű: állítsátok be a PTR rekordot jól.

Az valószínűleg jól van beállítva. A probléma szerintem az, hogy a küldő domain-je nem az O365-re van felhúzva. Feltételezem máshova mutat a domain PTR-je. Így egy csomó szerver el fogja dobni. A megoldás: úgy kell az O386-ön keresztül küldeni, hogy a domain fel van konfigurálva az O365-re.

Persze, ehhez vagy teljesen vagy hibrid módban kell az O365-öt használni. Ennyi infóból nem derül ki, hogy wtf, szóval több infó kéne.

trey @ gépház

elvileg jók a dns beállítások. Eddig ment. A Outlook-ból küldött levelekkel semmi gond. Itt csak valamiért az SMTP kapcsolaton keresztül küldött levelek vannak eldobva. Anno, amikor migráltuk a helyi fiókokat O365-re rendben lefutott minden domain beállítás. Ha elküldöm neked privibe valahogy a domain-t meg tudnád kukkantani, hogy szerinted így jó-e?

Pontosan írd le a levél útját ide. Honnan hova megy. Az érzékeny adatokat hagyd ki.

Ami nekem működik:

Céges hálózaton belül indított levél (mondjuk programból, eszközről (pl. buta scanner) vagy menedzsment eszközről) -> helyi anon relay szerver, ami csak bizonyos IP-kről fogadva el a levelet -> smarthost -> smtp.office365.com (név/jelszó Basic auth. / TLS és a feladó egy létező, postafiókkal rendelkező O365 user)

trey @ gépház

Nálunk így működik a problémás esetben:   céges hálózaton működő windowsos ügyviteli programból levél -> smtp.office365.com ( létező postafiókkal rendelkező user küldi a levelet másik e-mail cím nevében (felhatalmazva az O365-ben küldés mint...) név/jelszó SSL/TLS

1) Mi dobja vissza? Másik e-mail szolgáltató vagy valami privát céges e-mail szerver?

2) Ha bemész a Microsoft 365 admin center -> Settings -> Domains -> <domain név> alá, ott a domain "Healty" (zöld)? Az MX, TXT (SPF), CNAME rekordok jók? 

3) A PTR rekord hova mutat? A céges hálózat publikus IP címére, amin keresztül kimegy a levél?

On behalf küldést nem teszteltem, nekem nevesített kiküldőm van (noreply).

trey @ gépház

Több ügyfelünk is jelezte, hogy kapta meg a bizonylatot. Nagy számban vannak, valószínű sokféle szolgáltatónál. Nem megy át semmilyen egyéb szerverünkön.

A DNS rekord az admin center szerint jó. A DNS-t nem az O365 kezeli, az egy külső szolgáltatónknál van. SPF is rendben van.

PTR rekord nincs a DNS-ünkben jelenleg. 

A régi PTR lényegében-lényegtelen szerintem, mert a tényleges küldő valamelyik MS szerver. Azt láttam, hogy ott van bibi, mert 2 szerveren megy át mire kézbesítésre kerül/ne. Persze ezeknél a reverse nem igazán ok így. Ez így nagyon gáz! Távszámlák mennek/mennének de így megbízhatatlanná válik. Csak amikor felszólítgatjuk az ügyfeleket akkor derül ki, hogy egyik megkapta, másik nem. ÁÁÁÁÁááááááá...

( mogorva v | 2020. 05. 06., sze – 10:01 )

Van egyáltalán PTR rekordotok?

Nálunk az volt a mondás, hogy az Azure-os DC-kben lévő mail szerverekre az MS nem ad PTR rekordot, mert "arra nincs szükség, elég az SPF és a DKIM".

Ezt most erősen challenge-eljük.

Kíváncsiságból megpróbálnám On Behalf nélkül. BTW: a szoftver, ami kiküldi mennyire szigorúan implementálja az RFC-ket? Nem megoldás, az amit említettem, hogy a helyi hálón van egy SMTP szerver, ami átveszi a levelet és azt küldi ki az O365-nek mint smarthost-nak?

trey @ gépház

Igen, így hajtjuk mi is. Annyi különbséggel, hogy egy Windows Server-re felhúzott IIS SMTP role-t használunk, hogy minél kisebb legyen az inkompatibilitás az O365 és a mi szerverünk közt. A Microsoftnál sosem lehet tudni, hogy éppen mit beszél tájszólással ;)

trey @ gépház

( akoska00 | 2020. 05. 06., sze – 13:28 )

Az egy érdekes kérdés, hogy ha az alkalmazás küldi a levelet akkor a DKIM fail, ha outlook emailt küldök akkor DKIM pass. A mail-tester szerint.