Ak odosielací systém hlási prijatie cez SMTP, no adresát správu nevidí, najprv overte, čo bolo skutočne prijaté a ktorým serverom. Úspešné prevzatie celého obsahu správy znamená prijatie zodpovednosti za jej doručenie alebo ďalšie odovzdanie. Nehovorí však, do ktorého priečinka ju služba zaradila, ani či ju adresát otvoril. Stav v aplikácii preto porovnajte s prenosovým záznamom.
Zistite, ktorý bod prenosu vidíte
Aplikácia často odovzdáva správu vlastnému odosielaciemu poskytovateľovi. Jeho úspešná odpoveď ešte nemusí byť odpoveďou servera adresáta. Rovnako nestačí úspech pri príkaze RCPT TO; potrebujete výsledok po odovzdaní obsahu. RFC SMTP odlišuje jednotlivé fázy, preto pri podpore žiadajte presnú odpoveď a kontext namiesto samotného štítku delivered.
Poradie praktických kontrol
- Zapíšte príjemcu, čas s časovým pásmom, predmet a Message-ID, ak ho máte. Overte adresu znakovým porovnaním; podobný alias alebo stará adresa môžu vyzerať presvedčivo, ale viesť inam.
- V odosielacej službe vyhľadajte poslednú udalosť pre konkrétneho príjemcu. Rozlíšte prevzatie do vlastného frontu, pokus o odovzdanie, úspech a neskoršiu správu o nedoručení.
- Zistite názov servera, ktorý prevzatie potvrdil, a fázu SMTP komunikácie. Ak vidíte len prvý relay, vyžiadajte pokračovanie trasy od jeho prevádzkovateľa.
- Požiadajte príjemcu o vyhľadanie správy vo všetkých priečinkoch a o kontrolu spamu, pravidiel a presmerovania. V organizácii môže správca overiť aj karanténu a sledovanie správ.
- Ak správu nenájdete, odovzdajte podpore časovú os, identifikátory a anonymizovaný záznam. Rozlíšte potvrdené fakty od hypotéz; samotná neprítomnosť v doručenej pošte neurčuje príčinu.
Príklad: potvrdenie od prvého servera
Predstavme si fakturačnú aplikáciu, ktorá úspešne odovzdá správu svojmu SMTP poskytovateľovi. V používateľskom rozhraní sa objaví úspech, ale poskytovateľ ju ešte spracúva. Účtovník považuje stav za konečné doručenie. Správny ďalší krok je získať udalosť odovzdania cieľovému serveru pre danú adresu. Tento hypotetický príklad nevysvetľuje automaticky každý chýbajúci e-mail.
V inom prípade už cieľová služba správu prijala, ale adresát ju nájde v archíve po použití vlastného pravidla. Rovnaký príznak v aplikácii teda môže mať inú príčinu. Preto nie je vhodné hneď meniť SPF, obsah alebo poštového poskytovateľa. Najprv určte posledný potvrdený krok, až potom navrhnite zmenu, ktorá s ním súvisí.
Ako urobiť kontrolný pokus
Nový pokus odošlite rovnakou cestou na vlastnú kontrolnú adresu a označte ho jednoznačným predmetom. Zaznamenajte nový čas a Message-ID, aby sa výsledok nezamenil so staršou správou. Neposielajte opakovane tú istú faktúru zákazníkovi bez kontroly, či prvá už nebola spracovaná. Kontrolná správa má pomôcť lokalizovať problém, nie nahradiť dôkaz o pôvodnom odoslaní.
Ak pri teste získate doručenú správu, jej hlavičky môžu ukázať trasu a overenie odosielateľa. Nepreukážu však, čo sa stalo s inou chýbajúcou správou. Bez záznamov oboch strán zostáva záver obmedzený. Pri eskalácii odstráňte obsah citlivých dokladov a zachovajte technické identifikátory potrebné na dohľadanie; heslá a prístupové tokeny do podkladu nepatria.
Ak podpora potvrdí odovzdanie cieľovému serveru, nadväzujúcu kontrolu musí spravidla vykonať správca prijímacej strany. Pošlite mu presné údaje na vyhľadanie namiesto všeobecného hlásenia. Rovnaký predmet môže mať viac správ, preto pri párovaní uprednostnite aj čas, príjemcu a dostupný identifikátor. Záver formulujte až podľa nájdeného záznamu.
Zdroje a ďalší krok
RFC 5321: prevzatie zodpovednosti po SMTP prijatí
Gmail: sledovanie správy pomocou hlavičky
Ak chcete porovnať správanie konkrétnej správy v dostupných testovacích schránkach, spustite test doručiteľnosti. Výsledok opisuje iba pozorovanú vzorku a čas testu; nepotvrdzuje doručenie všetkým zákazníkom ani pokrytie slovenských poskytovateľov.
Rozsah merania a jeho obmedzenia opisuje metodika testovania.