Модул 6 · 6.2

Български

Nederlands English Deutsch Français Español Italiano Polski Română Čeština Ελληνικά Magyar Slovenčina Български

Често срещани кодове за грешки обяснени

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

Цел на урока: След този урок ще разпознавате кодовете за грешки, които срещате най-често, ще знаете каква е причината и кой трябва да я отстрани: Вие като подател, получателят или администраторът на пощенски сървър.

Основни понятия: адресът е неизвестен (5.1.1), mailbox пълна (4.2.2 / 5.2.2), съобщението е твърде голямо (5.3.4), няма маршрут (5.4.x), изтекло във опашката (4.4.7), relay отказан (5.7.1), не е удостоверено (Gmail 5.7.26), липсва PTR (Gmail 5.7.25), твърде висок темп (4.7.28), Microsoft 4.7.500, 5.7.509, 5.7.515, 5.7.606, 5.7.708, IP блокада на T-Online, лимит за изпращане

Първо: кой трябва да направи нещо?

Един код за грешка е полезен едва когато знаете кой трябва да действа. Затова първо класифицирайте всеки bounce в една от следните четири категории:

Адресът или mailbox-ът на получателя (5.1.x, x.2.x): адресът не съществува, или mailbox-ът е пълен или деактивиран. Вие можете само да проверите адреса или да предупредите получателя по друг начин.
Вашите настройки като подател (например 5.7.1 relaying denied, грешки при вход, лимит за изпращане): Вие коригирате нещо в пощенската си програма или в пакета си.
Вашият домейн (SPF, DKIM, DMARC; Gmail 5.7.26, Microsoft 5.7.509 и 5.7.515): Вие коригирате своя DNS, или възлагате това на някого.
Сървърът за изпращане (PTR, блок списък, репутация; Gmail 5.7.25 и 4.7.28, Microsoft 4.7.500 и 5.7.606, T-Online): администраторът на сървъра решава проблема. При хостинг пакет или пощенска услуга това е Вашият доставчик.

Адрес и mailbox

Код (примерен текст)	Причина	Какво правите?
`550 5.1.1 User unknown`, `Recipient address rejected`, `mailbox unavailable`	Адресът не съществува при получателя	Проверете правописа. Ако е правилен, попитайте получателя по друг начин дали адресът все още съществува
`550 5.1.10` (Microsoft), `RecipientNotFound`	Същото при Microsoft 365	Същото
`5.1.2`, `Host or domain name not found`	Домейнът не съществува или няма пощенски сървър (нито MX, нито A)	Печатна грешка в домейна (`gmial.com`)? Или домейнът на получателя е изтекъл или е неправилно настроен
`452 4.2.2` или `552 5.2.2`, `mailbox full`, `quota exceeded`, `out of storage space`	Mailbox-ът на получателя е пълен	Получателят трябва да освободи място. При `4.2.2` Вашият сървър все още опитва отново; при `5.2.2` е окончателно. Gmail използва `552 5.2.2` за пълен mailbox, който вече дълго не се използва
`450 4.2.1`, `receiving mail too quickly`	Получателят получава твърде много поща за кратко време	Изчакайте, Вашият сървър ще опита отново
`552 5.3.4`, `message size exceeds`, `message too big`	Съобщението с прикачени файлове е по-голямо от разрешеното от получателя	По-малък прикачен файл, или споделете файла чрез линк. Имайте предвид: прикачените файлове стават около една трета по-големи поради кодирането (урок 3.2)

Вашите собствени настройки за изпращане

Код (примерен текст)	Причина	Какво правите?
`550 5.7.1 Relaying denied`, `Relay access denied`	Вашата пощенска програма не влиза в изходящия сървър и той отказва да препраща поща към други домейни	Включете удостоверяването за изходящия сървър (урок 1.4, 2.1)
`535 5.7.8 Authentication failed`	Грешно потребителско име или парола при изпращане	Пълен имейл адрес като потребителско име, тествайте паролата в уебмейла
`550 5.4.5 Daily sending quota exceeded`, `message limit reached`	Достигнали сте лимита за изпращане на Вашия mailbox или пакет	Изчакайте лимитът отново да се освободи. Не изпращате много поща? Тогава mailbox-ът Ви може да е злоупотребен: сменете веднага паролата
`553 5.7.1 ... not owned by user`, `can not send emails from`	Адресът на подателя не принадлежи на mailbox-а, с който влизате	Изпращайте от собствения си адрес, или настройте псевдонима (alias), както предписва Вашият доставчик (урок 3.3)
`4.4.7`, `Message expired`, `retry timeout exceeded`	Пощата е стояла дни наред в опашката и не е могла да бъде доставена	Погледнете по-ранните съобщения за забавяне: те съдържат истинската причина

Вашият домейн: удостоверяване

Код (примерен текст)	Причина	Какво правите?
`550 5.7.26 ... sender is unauthenticated` (Gmail)	SPF и DKIM не успяват и двете, или DMARC се проваля	Допълнете SPF с услугата, която е изпратила, включете DKIM, проверете подравняването (модул 4)
`550 5.7.27` (Gmail)	SPF се провали	Включете сървъра за изпращане във Вашия SPF; внимавайте за десетте справки (lookup)
`550 5.7.30` / `421 4.7.30` (Gmail)	DKIM се провали	Проверете DKIM ключа със селектора от писмото
`421 4.7.32` / `550 5.7.32` (Gmail)	Домейнът `From:` не е подравнен със SPF или DKIM	Собствен DKIM за Вашия домейн при услугата за изпращане, или собствен Return-Path
`421 4.7.31` (Gmail)	Подател на масова поща без DMARC запис	Поставете DMARC запис, поне `p=none`
`550 5.7.509 Access denied, sending domain ... does not pass DMARC verification and has a DMARC policy of reject` (Microsoft)	DMARC се проваля и собствената Ви политика е зададена на `reject`	Разберете кой източник не е подравнен (DMARC отчет, урок 4.5). Точно затова се започва с `p=none`
`550 5.7.515 Access denied, sending domain ... does not meet the required authentication level` (Microsoft)	Подател на масова поща към Outlook.com, при когото SPF или DKIM се провалят, или липсва DMARC	Нека и SPF, и DKIM успеят, DMARC запис (урок 5.3)
`550 5.7.23 ... Sender Policy Framework violation` (Microsoft)	SPF се проваля при получател, който филтрира строго по SPF	Допълнете SPF
`550 5.7.1 DMARC check failed` (други сървъри)	Същото, с общ код	Същото

Нещо, за което да внимавате при 5.7.509: bounce-ът посочва Вашия домейн, но причината невинаги е обичайната Ви поща. Често е уебсайт, онлайн магазин или счетоводен пакет, който изпраща от името на Вашия домейн, без тази услуга да е включена във Вашия SPF или да подписва с Вашия DKIM. Погледнете в кополовките на оригиналното писмо в долната част на bounce-а за Return-Path и изпращащия сървър.

Сървърът за изпращане: PTR, репутация и блок списъци

Код (примерен текст)	Причина	Кой го решава?
`550 5.7.25 ... doesn't have a PTR record` (Gmail)	IP адресът на сървъра за изпращане няма (правилен) обратен DNS запис, често чрез IPv6	Администраторът на сървъра (урок 5.1)
`421 4.7.23` (Gmail)	Същото, временен вариант	Същото
`550 5.7.29` / `421 4.7.29` (Gmail)	Не е изпратено чрез TLS	Администраторът на сървъра
`421 4.7.28 ... unusual rate of email` (Gmail), `550 5.7.28 ... unusual rate of unsolicited email`	Твърде много поща или твърде много нежелана поща от този IP адрес	Намалете темпото; при окончателен отказ първо решете причината (спам, купен списък)
`451 4.7.500 Server busy. Please try again later from [IP]` (Microsoft)	Microsoft временно забавя IP адреса, често защото е нов или обемът внезапно нараства	Изчакайте, сървърът ще опита отново; администраторът загрява IP адреса и го регистрира в SNDS (урок 6.4). Microsoft документира серията от `4.7.500` до `4.7.699` и като "Access denied, please try again later" при подозрителна активност
`550 5.7.606` до `5.7.649 Access denied, banned sending IP [IP]` (Microsoft)	IP адресът е блокиран от Microsoft	Администраторът подава заявка за премахване чрез sender.office.com, след решаване на причината
`550 5.7.708 Access denied, traffic not accepted from this IP` (Microsoft 365, изходящ)	Трафикът от този IP адрес или тази среда на Microsoft 365 не се приема, често след злоупотреба	Администраторът на средата на Microsoft 365, чрез поддръжката на Microsoft
`554 ... blocked using zen.spamhaus.org`, `listed at`, `RBL`	IP адресът е в блок списък	Администраторът на сървъра, след решаване на причината (урок 5.2)
`554 IP=192.0.2.25 - A problem occurred` и подобни съобщения с "bad reputation" (T-Online)	T-Online е блокирал IP адреса въз основа на собствени данни за репутация	Администраторът на сървъра за изпращане се свързва с T-Online (урок 6.4)
`421 Maximum parallel connections for your IP-Address reached` (T-Online)	Твърде много едновременни връзки	Администраторът ограничава броя на връзките; писмото все пак пристига по-късно

Как да потърсите непознат код?

Проверете кой го е дал. Името в Remote-MTA или след host показва коя страна е това: google.com, outlook.com или protection.outlook.com, t-online.de, и така нататък.
Потърсете кода при тази страна. Google има страница "Gmail SMTP errors and codes", Microsoft "Email nondelivery reports and SMTP errors in Exchange Online", а Yahoo и T-Online имат postmaster страници. Те са по-надеждни от случаен форум.
Прочетете текста след кода. При големите получатели често има линк или код в скоби (като (AS843) при Microsoft), който казва точно какво се случва.
Погледнете оригиналното писмо в долната част на bounce-а. Кой адрес на подателя, кой Return-Path, кой сървър? При SPF и DMARC грешки отговорът е там.

На практика

При WebOké в базата знания има списък с често срещани съобщения, а в DirectAdmin в E-mail Tracking виждате буквалния отговор на получаващия сървър. При други доставчици подобен log обикновено също съществува, понякога само за администратора. Ако поискате помощ от доставчик, винаги изпратете целия bounce, заедно с реда с кода, адреса на подателя, адреса на получателя и момента на изпращане. Обобщение от сорта "моята поща не пристига" не позволява на никого да провери нещо.

Обобщение

Класифицирайте всеки код първо: адрес/mailbox на получателя, Вашите настройки за изпращане, Вашият домейн, или сървърът за изпращане.
5.1.1 адресът не съществува, x.2.2 mailbox пълен, 5.3.4 твърде голямо, 5.7.1 relaying denied не е влязъл в сметката.
Удостоверяване: Gmail 5.7.26/5.7.27/5.7.30, Microsoft 5.7.509 (DMARC с reject) и 5.7.515 (масова поща).
Сървър: Gmail 5.7.25 (PTR), Microsoft 4.7.500 (временно забавен) и 5.7.606 (IP блокиран), IP блокади на T-Online.
Потърсете непознат код при страната, която го е дала, и прочетете оригиналното писмо в долната част.

Тест

Задача

Задача Z6.2: Свързване на код и причина. Получавате десет реални съобщения за грешка (с примерни домейни и адреси на документация) и списък с причини и с това кой трябва да действа. Свържете всяко съобщение с правилната причина и правилната страна. Програмата проверява с фиксиран ключ и дава обяснение за всеки грешен отговор.

Задача Z6.2: Свързване на код и причина

Свържете всяко съобщение с причина и със страната, която трябва да предприеме действие. Страна: O = получателят, J = Вие като подател, D = Вашият домейн/DNS, S = администраторът на сървъра за изпращане.

M1: 550 5.1.1 <sales@example.net>: Recipient address rejected: User unknown

M1: кой трябва да предприеме действие?

M2: 552 5.2.2 The recipient's inbox is out of storage space and inactive.

M2: кой трябва да предприеме действие?

M3: 550 5.7.1 <klant@example.org>: Relay access denied (при изпращане от Вашия пощенски клиент)

M3: кой трябва да предприеме действие?

M4: 550 5.7.26 This email has been blocked because the sender is unauthenticated. (Gmail)

M4: кой трябва да предприеме действие?

M5: 550 5.7.25 This message was blocked because the sending IP address doesn't have a PTR record. (Gmail)

M5: кой трябва да предприеме действие?

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

M6: кой трябва да предприеме действие?

M7: 550 5.7.606 Access denied, banned sending IP [203.0.113.25]. (Microsoft 365)

M7: кой трябва да предприеме действие?

M8: 552 5.3.4 Message size exceeds fixed maximum message size

M8: кой трябва да предприеме действие?

M9: 550 5.7.509 Access denied, sending domain EXAMPLE.COM does not pass DMARC verification and has a DMARC policy of reject.

M9: кой трябва да предприеме действие?

M10: 554 IP=203.0.113.25 - A problem occurred. (T-Online)

M10: кой трябва да предприеме действие?

Това, което въвеждате, и резултатите от проверката не се съхраняват. Браузърът Ви запомня отговорите и дали сте изпълнили задачата. Ако сте влезли, запазваме само дали задачата е била (почти) правилна в Моите курсове; и там можете да го изтриете.

Препоръчано четене

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

Бисквитки в WebOké

Настройки за бисквитки

Необходими

Маркетинг