Hlavní navigace

Šťoura: Na POST nešla doručit pošta

Marek Antoš

Píšu si poměrně často s jednou kamarádkou, která má schránku na serveru POST.CZ, což je jistá nevýhoda pro jeho provozovatele, protože mám četné vlastní zkušenosti s tím, když se někde vyskytne nějaký problém. Tentokrát jsem tedy vlastnoručně vyšťoural, že na POST nešla doručit pošta kvůli špatně nastavenému MX záznamu.

Vzhledem k tomu, že nás nečtou jen samí experti přes nastavování nameserverů, neuškodí si připomenout, co to vlastně MX záznam je. Zjednodušeně řečeno MX záznam říká, na který konkrétní server se má doručovat pošta pro určitou doménu. Je přitom možné určit více serveru a stanovit jim priority – čím nižší číslo se uvede, tím vyšší prioritu má. V případě POSTu, jehož MX záznam za chvilku uvidíte, tak se tak pošta nejprve snaží doručit na server smtp.post.cz, pokud ten nepřijímá (nebo je nedostupný), následuje ms.globe.cz, a teprve ve finále nastupuje smtp.vol.cz. Je ovšem třeba zdůraznit, že do MX záznamů nelze nacpat co vás napadně; dotyčné servery musí být nastaveny tak, aby měly povolený příjem pošty pro danou doménu.

Příslušný MX záznam pro doménu post.cz tedy vypadá takto:

                1D IN MX        30 smtp.vol.cz.
                1D IN MX        20 ms.globe.cz.
                1D IN MX        10 smtp.post.cz.

Dva mailservery jsou tedy v režii provozovatele POSTu a teprve třetí, coby malý záchranný pás, je u samotného poskytovatele připojení, tedy u Video On Line. Na první pohled vše vypadá v pořádku a jak si může mnohý uživatel POSTu ověřit podle pošty, kterou přijímá, také to funguje. Předevčírem jsem však narazil na malý problém.

Odeslal jsem zprávu na POST a hle, za chvilku byla zpátky chybová hláška, signalizující, že zprávu nebylo možné doručit a že ji mailserver zahodil:

---- The following addresses had permanent fatal errors ----
<xxx.yyy@post.cz>
---- Transcript of session follows ----
... while talking to smtp.vol.cz.:
>>> RCPT To:<xxx.yyy@post.cz>
<<< 550 <xxx.yyy@post.cz>... Relaying denied
550 <xxx.yyy@post.cz>... User unknown

Vtip byl v tom, že oba „vlastní“ mailservery Globe v té chvíli z nějakého důvodu nefungovaly a můj mail tak přepadl na třetí server v pořadí, tedy ten přímo u VOL. Ten však nebyl nastaven jako tzv. relay pro doménu post.cz a můj mail proto odmítl. Musel jsem ho tedy později, když už zbylé mailservery zase naskočily, poslat znovu.

Jak nám řekl Jan Panoch, správce POST.CZ, kterého jsem na problém upozornil, příčinou byla chybná domluva s VOL. Díky tomu, že se stává jen výjimečně, aby neběžel ani jeden ze dvou mailserverů Globe, na tuto zapeklitost zatím nikdo nepřišel. Jak jsem pozoroval podle změn v DNS, vzápětí po mém dotazu zmizel třetí mailserver z DNS, čímž byl problém pro danou chvíli vyřešen. Vrátil se tam již druhý den, tentokrát však již řádně nastavený.

Při této příležitosti jsem se podíval, jakým způsobem mají MX záznamy řešeny ostatní české free-mailové služby. POST.CZ z nich v této chvíli se svými dvěma vlastními mailservery a jedním u poskytovatele připojení vychází jako vítěz. Dalším v pořadí je zřejmě Mail Atlasu, který používá jeden svůj a jeden u poskytovatele, Seznam E-mail naproti tomu nabízí sice rovněž dva mailservery, ale oba své vlastní. Výtku musím směřovat směrem k ATC Organizéru, který nabízí jen jeden, svůj, relay. Z hlediska jeho uživatelů to není podstatné, ale zatěžuje to ostatní SMTP servery – pokud někdo pošle dopis někomu na e-mail.cz a právě neběží relay, musí se uchovat ve frontě odesílajícího SMTP serveru, který pak periodicky zkouší, zda už cílový server náhodou neběží a nepříjímá. V případě větších objemů zpráv to už je poměrně zatěžující.

UX17_snitker

Marek Antoš


Starší, související články:

Našli jste v článku chybu?