Назвіть одну вагому причину негайного відмови у коді SMTP 4xx

Мені це дуже цікаво. Питання (виділено жирним шрифтом):

Чи може хтось назвати ОДИН ДОБРИЙ ПРИЧИНУ, щоб їх сервер електронної пошти постійно був налаштований на автоматичну відмову / негайну помилку на 4xx-кодах?

Бо, чесно кажучи, це звучить як "їхні" налаштування вибиті з нестабільності. SMTP не є миттєвим повідомленням. Перестаньте ставитися до цього, як IRC, або Jabber, або MSN, або вставте тут-IM-технологію . Я не знаю, чим володіють люди, які мають менталітет "НЕМОВНА ДОСТАВКА АБО НЕ ПОСТАВКА" з налаштуваннями SMTP, але їм потрібно припиняти це робити. Це просто пробиває речі. Кожні два-три роки я натрапляю на це. Хтось десь вирішив своєю нескінченною мудрістю, що 4хx-коди - це негайні збої, і раптом його OMGWTFBBQ ІНТАРНЕТЦЬ БОРОТЬ, НАЛИЧНИЙ СКІЙ ВІН падає замість "о, це буде повторна спроба доставки приблизно за 30 хвилин". Мене дивує, як раптом стає "моєю" проблемою те, що повідомлення не пройде, неправильно налаштував "свою" службу SMTP.

Якщо є законна причина постійного налаштування вашого сервера, тоді першою вдалою відповіддю буде перевірка.

Якщо немає вагомих причин (і я підозрюю, що їх немає), тоді перша відповідь, яка добре звучить, якщо все-таки є логічно несправною, отримає перевірку.

Я встановив це один раз таким чином, оскільки власник хотів дізнатися, коли електронні листи будуть відкладені, і якщо так, він хотів змінити текст електронної пошти. Це було для торговельної кадри, тому я можу зрозуміти необхідність своєчасності. Окрім чогось подібного, я не можу уявити, чому (і я думав, що це колись у синьому місяці)

Від RFC:

4.X.X   Persistent Transient Failure

   A persistent transient failure is one in which the message as
   sent is valid, but some temporary event prevents the successful
   sending of the message.  Sending in the future may be successful.

Цілком зрозуміло, що 4xx слід надсилати лише у відповідь на тимчасову (тимчасову, що погана формулювання) проблема. Звідси випливає, що немає жодних виправданих причин трактувати це як негайну помилку. На це слід реагувати на звичайні спроби.

Зважаючи на це, надмірне використання жирних і курсивних текстів пропонує вам поставитися до цього питання не тільки серйозно, але й особисто. Найкраще, що я можу запропонувати, - це просто розслабитися і не засмучуватися та напружуватися над чужим ідіотизмом.

Коли хтось скаржиться, просто вкажіть на цю частину RFC (залишаючи поза увагою той факт, що RFC не є стандартом) і нагадайте їм, що у вас немає контролю над тим, як інші налаштовують свої системи.

Думаючи про це, я, можливо, можу подумати, що може виникнути якась DoS-атака, якщо запустити зсередини, де клієнт надсилає лайно завантаження електронних листів на відомі недійсні сервери smtp. Це призведе до того, що поштовий сервер почне накладати більше навантаження на себе, оскільки він намагається повторно надіслати.

Я б не назвав це вагомою причиною, але, можливо, це принаймні "гарне звучання"? :-)

Можливо, ще одна причина може бути: "Якщо це не спрацювало з першого разу, воно, ймовірно, не вийде, тому повідомляємо користувача про це відразу. І я не знаю, як зробити так, щоб він тривав повторний пошук". . Це звучить для мене ще більш кульгаво ...