Nehéz címzettek: Microsoft és T-Online

Modul 6: Bounce-ok és hibaelhárítás · Olvasási idő: 11 perc

Tanulási cél: Ennek a leckének a végén Ön ismeri két olyan címzett saját szabályait, akik gyakran okoznak kérdéseket, a Microsoft (Outlook.com, Hotmail és Microsoft 365) és a T-Online, és tudja, mit tehet felhasználóként, és mit tehet a küldőszerver üzemeltetője egy késleltetés vagy blokkolás esetén.

Kulcsfogalmak: Outlook.com és Exchange Online Protection, reputáció nélküli új IP-cím, 451 4.7.500 Server busy, 550 5.7.606 banned sending IP, delist-portál sender.office.com, SNDS, JMRP, Levélszemét mappa, biztonságos feladók, T-Online, saját reputációrendszer, forward-confirmed reverse DNS, elérhetőségi adatok a PTR-domain weboldalán, nincs whitelisting, postmaster.t-online.de

Miért éppen ez a kettő?

A Microsoft fogadja az Outlook.com, a Hotmail és a Live.com leveleit, emellett a vállalatok nagy részének levelezését is (a Microsoft 365-ön keresztül, az Exchange Online Protection szűrővel). A T-Online Németország legnagyobb levelezési szolgáltatása. Mindkettő a szokásos szabványok mellett saját reputációrendszert is használ. Az a levél, amely a Gmailnél simán megérkezik, náluk késleltetve lehet vagy elutasítható. Aki ügyfelekkel vagy kapcsolatokkal rendelkezik Németországban, vagy sokat levelez Hotmail-címekre, előbb-utóbb ezzel szembesül.

Microsoft: ideiglenes lassítás a 4.7.500 kóddal

A Microsoft legismertebb hibaüzenete:

451 4.7.500 Server busy. Please try again later from [203.0.113.25]. (AS843)

A szöveg azt mondja, „szerver foglalt”, de ez nem pontos: ez egy szándékos lassítás. A Microsoft ezt a kódsorozatot (4.7.500 és 4.7.699 között) akkor használja, ha egy küldő IP-címnek még kevés a reputációja, vagy ha a viselkedés hirtelen megváltozik, például a levelek számának erős növekedésekor. A Microsoft ezt saját maga ideiglenes korlátozásként írja le, amely a gyanús tevékenység értékelését szolgálja, és magától feloldódik, ha a levelezés rendben lévőnek bizonyul.

Ez mit jelent az Ön számára?

• Ez egy ideiglenes hiba (4xx). A küldő szerver megőrzi a levelet, és újra megpróbálja kézbesíteni. Rendszerint a levél egy vagy több próbálkozás után mégis megérkezik, néha órák múlva.
• Ha halasztási üzenetet kap, a levelet ne küldje el újra. Ez csak növeli a mennyiséget, és súlyosbítja a lassítást.
• Ha ez Önnek problémát okoz (például belépési kódok vagy számlák esetén, amelyeknek azonnal meg kell érkezniük), jelentse ezt a szolgáltatójának, mellékelve a halasztási üzenetet.

Amit a küldőszerver üzemeltetője tehet:

1. Ellenőrizze, hogy az alapok rendben vannak-e: PTR FCrDNS-sel, nincs blocklistán, SPF és DKIM a szerveren keresztül levelező domainekhez (lecke 5.1 és 5.2).
2. Bemelegítés (warming up): egy új IP-cím kezdetben a forgalom kisebb részét küldje, és fokozatosan egyre többet.
3. A tempó korlátozása címzettenként: kevesebb egyidejű kapcsolat a Microsoft felé, és ésszerű várakozási idő a próbálkozások között, hogy a szerver ne ütközzön folyamatosan a fékbe.
4. Regisztráció az SNDS-nél és a JMRP-nél (lásd alább).

Microsoft: blokkolás az 5.7.606 kóddal

Ha az IP-cím valóban blokkolva van, végleges hibát kap:

550 5.7.606 Access denied, banned sending IP [203.0.113.25]. To request removal from this list please visit https://sender.office.com/ and follow the directions.

Ez Microsoft 365-környezetekbe küldött levelek esetén fordul elő. Az IP-cím üzemeltetője eltávolítást kérhet a delist-portálon, a sender.office.com oldalon: meg kell adni az e-mail-címet és az IP-címet, meg kell nyitni a megerősítő levelet, és ott ki kell választani a „Delist IP” opciót. A Microsoft szerint ez után akár 24 órát is igénybe vehet, mire a blokkolás megszűnik. Előbb azonban oldja meg az okot: egy olyan IP-cím, amely az eltávolítás után ismét spamet küld, gyorsan visszakerül a listára.

Az Outlook.com és a Hotmail esetében (a fogyasztói oldal) az eltávolítás a Microsoft feladótámogatásának külön űrlapján keresztül történik. A Microsoftnál nem létezik kézi whitelist: ez mindig egy automatikus reputációrendszer marad.

Microsoft: SNDS és JMRP

A Microsoft két ingyenes szolgáltatást kínál a küldő IP-cím üzemeltetőinek:

• SNDS (Smart Network Data Services): IP-címenként láthatja, hány levelet kapott a Microsoft, ebből mennyit minősítettek spamnek, hány panasz érkezett, és hogy a cím bekerült-e spamcsapdákba. Egy színkód (zöld, sárga, piros) mutatja az állapotot.
• JMRP (Junk Mail Reporting Program): ha egy Outlook.com-felhasználó az Ön levelét nem kívánt levélként jelöli meg, Ön egy másolatot kap róla. Így látható, mely levelek okoznak panaszt.

Mindkettő csak annak hasznos, aki saját maga üzemeltet egy IP-címet: saját szerver, vagy egy megosztott szerver szolgáltatója. Egy tárhelycsomag vagy levelezési szolgáltatás egyszerű felhasználójaként Ön ide nem regisztrál saját maga.

Microsoft: a Levélszemét mappában

Gyakran a levelet nem utasítják el, hanem a Levélszemét mappába kerül, különösen azoktól a feladóktól, akiket a Microsoft még nem ismer. Ilyenkor hibakódok nem segítenek, mert nincs bounce. Ami működik:

• SPF, DKIM és DMARC rendben (4. modul). Ha Ön tömeges küldő, a Microsoft megköveteli, hogy az SPF ÉS a DKIM is sikeres (pass) legyen (lecke 5.3).
• Kérje meg állandó kapcsolatait, hogy adják hozzá az Ön címét a névjegyeikhez vagy a biztonságos feladókhoz, és a Levélszemétben lévő leveleket jelöljék meg „Nem levélszemét”-ként. Ez beleszámít a reputációba.
• Ne küldjön hírleveleket a szokásos postafiókján keresztül (lecke 7.1).

T-Online: saját rendszer

A T-Online (a Deutsche Telekom levelezési szolgáltatása, @t-online.de és @magenta.de címekkel) szigorú saját szabályairól ismert. A postmaster.t-online.de oldalon találhatók a küldőszerverekkel szemben támasztott elvárások. A legfontosabbak:

1. Az internetszabványok követése, köztük az SMTP-re és az üzenetek felépítésére vonatkozó RFC-k, valamint a forward-confirmed reverse DNS (lecke 5.1).
2. A reverse DNS-ben szereplő névnek egy olyan domainre kell mutatnia, amelynek weboldalán szerepel, hogyan lehet közvetlenül elérni az üzemeltetőt. A T-Online ennél az elektronikus kereskedelemről szóló európai irányelvre (2000/31/EK irányelv, 5. cikk) hivatkozik, amely a szolgáltató kötelező adatairól rendelkezik. Németországban egy ilyen oldalt Impressumnak neveznek.
3. Nincs közvetlen levélküldés dinamikus címekről, betárcsázós kapcsolatokról vagy „névtelen” felhőszerverekről: ezeknek egy megfelelő szolgáltató relayjén keresztül kell küldeniük.
4. Az egyidejű kapcsolatok számának korlátozása. Túl sok esetén a 421 Maximum parallel connections for your IP-Address reached üzenetet kapja.
5. Nincs nyitott relay, a kimenő levelezés szűrve van spam és vírusok szempontjából, és TLS esetén érvényes tanúsítvány szükséges.

Egy IP-cím blokkolása a T-Online-nál például így néz ki:

554 IP=203.0.113.25 - A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.)

A gyakorlatban olyan változatokkal is találkozhat, amelyek rossz vagy hiányzó reputációra utalnak. Az üzenet mindig ugyanaz: ez az IP-cím jelenleg nem kézbesíthet.

T-Online: mit tehet?

A T-Online kifejezetten közli, hogy nem kínál whitelistinget. Egy blokkolt cím azonban feloldható, ha az ok megszűnt. Az odáig vezető út:

• Egyszerű felhasználóként (Ön egy tárhelycsomagon vagy levelezési szolgáltatáson keresztül levelezik): küldje el a teljes bounce-ot a szolgáltatójának. Csak a küldőszerver üzemeltetője veheti fel a kapcsolatot a T-Online-nal; Ön saját maga nem tudja feloldatni az IP-címet.
• A küldőszerver üzemeltetőjeként: először ellenőrizze a fenti elvárásokat (PTR, FCrDNS, egy elérhető weboldal elérhetőségi adatokkal a PTR-ben szereplő domainen, nincs blocklist), majd lépjen kapcsolatba a hibaüzenetben megadott címen, vagy a postmaster.t-online.de oldalon található kapcsolatfelvételi űrlapon keresztül. Ismétlődő, ismeretlen okú ideiglenes blokkolások esetén a T-Online a postmaster-címet említi. Ne számítson visszaigazolásra.
• Rövid távon: egy fontos T-Online-címzettnek szóló levél ideiglenesen egy másik útvonalon (egy másik szolgáltatón vagy küldőszolgáltatáson) keresztül küldhető, vagy megegyezhetnek egy másik címben.

És a többiek?

Más nagy német szolgáltatóknak, mint a GMX és a Web.de, és sok vállalati szűrőnek is saját reputációrendszere van. A minta mindenhol ugyanaz: egy küldőszerver, amelynek rendben van a PTR-je, jó a hitelesítése, nyugodt és rendszeres a küldési mintája, és kevés a panasz, szinte mindenhová bejut. Probléma esetén olvassa el a bounce-ot, keresse ki a kódot az adott félnél, és bízza a kezelést a küldőszerver üzemeltetőjére.

Összefoglalás

• A Microsoft 451 4.7.500 Server busy üzenete az IP-cím szándékos, ideiglenes lassítása, gyakran alacsony reputáció vagy erős növekedés esetén. Ne küldje el újra.
• Az 550 5.7.606 blokkolt IP-címet jelent; az üzemeltető az ok megoldása után a sender.office.com oldalon keresztül kérheti az eltávolítást.
• Az SNDS és a JMRP betekintést ad az IP-cím üzemeltetőinek a Microsoftnál lévő reputációjukba.
• A T-Online többek között FCrDNS-t és a PTR-ben szereplő domainen elérhetőségi adatokkal rendelkező weboldalt kér, és nem kínál whitelistinget.
• Felhasználóként ezt saját maga nem oldja meg: adja át a teljes bounce-ot a szolgáltatójának.

Kvíz

Feladat

Feladat O6.4: Blokkolás kivizsgálása egy nagy fogadónál. Egy esettanulmányt kap: egy egyesület egy hete egy új, saját szerveren keresztül küldi a leveleit; a Hotmail-címekre küldött levelek órákkal később érkeznek meg, a T-Online-címekre küldött levelek pedig IP-blokkolással térnek vissza. Válaszoljon a következőkre: (1) mit jelent a két üzenet, (2) kinek mit kell tennie, (3) melyik öt dolgot ellenőrzi a szerveren, és (4) mit tehet az egyesület rövid távon? Ezután megtekintheti a mintaválaszt.

További olvasnivaló

Az ezekben a cikkekben leírt lépések a WebOké vezérlőpultjaira vonatkoznak; más szolgáltatóknál ez hasonlóan működik.

• Nem érkezik meg az e-mail, vagy a spam mappában landol: így lehet kideríteni az okát
• Levelek küldése a VPS-ről és a reverse DNS beállítása
• DirectAdmin útmutató 9.4: A levelem a címzettnél a levélszemétbe kerül
• Microsoft, Email nondelivery reports and SMTP errors in Exchange Online: https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online
• Microsoft, Office 365 Anti-Spam IP Delist Portal: https://sender.office.com/
• Microsoft, SNDS és JMRP: https://sendersupport.olc.protection.outlook.com/snds/
• T-Online Postmaster (elvárások és kapcsolatfelvétel): https://postmaster.t-online.de/