Четене на bounce съобщение

Модул 6: Съобщения за грешки и отстраняване на проблеми · Време за четене: 11 минути

Учебна цел: След този урок ще можете да анализирате съобщение за грешка относно недоставена поща (bounce): коя сървър е дал грешката, за кой адрес, какво означава кодът и дали е временна или окончателна грешка.

Основни понятия: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, код за отговор (RFC 5321), разширен код за състояние X.Y.Z (RFC 3463), съобщение за забавяне, backscatter

Какво е bounce?

Когато пощенски сървър не може да достави писмо, той изпраща съобщение обратно до подателя. Това се нарича bounce (или: non-delivery report, NDR). То идва от подател като Mailer-Daemon@..., MAILER-DAEMON или Mail Delivery System, с тема като:

• Mail delivery failed: returning message to sender
• Undelivered Mail Returned to Sender
• Delivery Status Notification (Failure)
• Warning: message ... delayed 24 hours (това не е bounce, а съобщение за забавяне, вижте по-долу)

Много хора веднага изтриват такова съобщение или се стряскат от английския текст. Жалко, защото bounce съобщението почти винаги показва точно какво не е наред. Просто трябва да знаете къде да гледате.

Bounce съобщението винаги има празен envelope подател (Return-Path: <>). Това е нарочно: bounce на bounce иначе би могъл да доведе до безкраен цикъл (RFC 5321).

Кой е отхвърлил писмото?

Писмото минава през поне два сървъра: този на Вашия доставчик и този на получателя. Bounce може да възникне в две ситуации:

1. Приемащият сървър отхвърля писмото по време на SMTP разговора (урок 1.2), например след RCPT TO (непознат адрес) или след съдържанието (спам или DMARC). Вашият собствен сървър получава този отказ и го превръща в bounce за Вас. Грешката идва тогава от получателя, а bounce съобщението от Вашия собствен сървър.
2. Вашият собствен сървър се отказва, например защото получателят е бил недостъпен дни наред или защото самите Вие сте достигнали лимит.

Разликата е важна: в първия случай трябва да знаете какво не е харесал получателят, във втория случай проблемът е по близо до Вас.

Четимата част

Отгоре стои текст за хора. Той се различава според пощенския софтуер, но почти винаги съдържа едни и същи неща:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pieter.devries@example.net
    host mx1.example.net [198.51.100.20]
    SMTP error from remote mail server after RCPT TO:<pieter.devries@example.net>:
    550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Четете го така:

Машинната част: DSN

Под текста обикновено стои част за програми, delivery status notification (RFC 3464). Тя винаги е изградена по един и същ начин, което я прави лесна за четене:

Reporting-MTA: dns; mail.hosting.example

Action: failed
Final-Recipient: rfc822;pieter.devries@example.net
Status: 5.1.1
Remote-MTA: dns; mx1.example.net
Diagnostic-Code: smtp; 550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Съвсем отдолу стои оригиналното писмо или само неговите кополовки. Там виждате кое писмо е било, и кой адрес на подателя и кой Return-Path са били използвани. Това понякога е ключът към решението (вижте DMARC казуса в задачата).

Четене на кодовете

Има два вида кодове и обикновено и двата присъстват в bounce съобщение.

Кодът за отговор (RFC 5321): три цифри, като 550 или 451. Първата цифра е най-важна:

Разширеният код за състояние (RFC 3463): три числа, разделени с точки, като 5.1.1 или 4.7.500. Първото число отново е 2, 4 или 5. Второто число показва къде е проблемът:

Третото число е точната причина. Големите получатели използват за това собствени номера, като Gmail с 5.7.25 до 5.7.30 и Microsoft с 4.7.500 и 5.7.509. Те са посочени в тяхната собствена документация (урок 6.2).

Практическо правило: кодът с 5 в началото и 7 в средата (5.7.x) почти винаги е въпрос на политика: автентикация, репутация или спам. Повторното изпращане не помага тук; трябва да се промени нещо.

Забавено все още не означава неуспешно

При временна грешка (4xx) Вашият сървър запазва писмото и опитва отново. RFC 5321 препоръчва да се издържи поне четири до пет дни, с поне половин час между опитите. Много сървъри изпращат след няколко часа или след ден съобщение за забавяне:

Action: delayed
Status: 4.7.500
Diagnostic-Code: smtp; 451 4.7.500 Server busy. Please try again later from [203.0.113.25].
Will-Retry-Until: Thu, 12 Nov 2026 08:58:40 +0100

Това означава: не изпращайте повторно, сървърът сам продължава да опитва. Ако все пак изпратите повторно, получателят може да получи писмото два пъти. Ако накрая не се получи преди Will-Retry-Until, все пак идва истински bounce, често с 4.4.7 (съобщението е изтекло в опашката).

Фалшиви bounce съобщения: backscatter

Получавате ли изведнъж десетки bounce съобщения за писма, които никога не сте изпращали? Погледнете тогава в оригиналното писмо отдолу. Ако там стои подател от Вашия домейн, но сървър и текст, които не познавате, значи спамър е използвал Вашия адрес като подател. Получателите изпращат своите bounce съобщения до Вас. Това се нарича backscatter.

Вашата mailbox тогава обикновено не е хакната (вижте урок 3.4 за разликата). Какво помага: DMARC политика, която постепенно става по-строга (урок 4.4), така че получателите да отхвърлят фалшифицираната поща, преди да възникне bounce. Проверете все пак в изпратената Ви поща и при доставчика си дали наистина нищо не е изпратено от Вашата mailbox.

На практика: ето как изглежда

При WebOké виждате освен bounce съобщението и в E-mail Tracking в DirectAdmin какво е направил сървърът със съобщението: Delivered, Deferred или Fail, заедно с отговора на приемащия сървър. Други панели често имат подобен mail log или „следа на съобщенията“; при Microsoft 365 например се нарича проследяване на съобщения. Полезно е първо да погледнете там, ако нямате bounce съобщение или някой каже, че писмото Ви не е пристигнало.

Обобщение

• Bounce съобщението идва от Mailer-Daemon и има празен Return-Path. Прочетете го, то почти винаги показва точно какво не е наред.
• Погледнете първо кой е дал грешката (SMTP error from remote mail server = получателят) и за кой адрес.
• В машинната част: Action, Status, Remote-MTA и най-вече Diagnostic-Code.
• Първа цифра: 4 = временно, 5 = окончателно. Второ число: 1 адрес, 2 mailbox, 3 система, 4 маршрут, 5 протокол, 6 съдържание, 7 политика.
• Съобщение за забавяне (delayed): не изпращайте повторно. Bounce съобщения за поща, която не сте изпращали: backscatter.

Тест

Задача

Задача Z6.1: Анализ на три bounce съобщения. Получавате три примерни bounce съобщения (bounce-1.txt, bounce-2.txt и bounce-3.txt). Попълнете за всяко: адресът, за който е възникнал проблемът, сървърът, дал грешката (Remote-MTA), кодът за състояние, дали е временна или окончателна грешка, и какво трябва да направи подателят (изберете от списък). Програмата проверява с фиксиран ключ и дава обяснение за всяко поле.

Допълнително четене

Стъпките в тези статии важат за панелите на WebOké; при други доставчици работи по подобен начин.

• Неуспешно доставяне на имейл (Mail delivery failed): как да разчетете съобщението за грешка и какво означават кодовете
• Съобщение за грешка: 550 5.5.0 Requested action not taken: mailbox unavailable
• Проверка дали имейлът е доставен с Email Tracking в DirectAdmin
• Ръководство за DirectAdmin 9.3: E-mail Tracking: къде се е дянала моята поща?
• RFC 3464 (структура на DSN), RFC 3463 (разширени кодове за състояние), RFC 5321 параграф 4.2 (кодове за отговор) и 4.5.4.1 (повторни опити)