Является ли это хорошей идеей сократить время отказа от доставки электронной почты?
У нас есть почтовый сервер для нескольких клиентов, и недавно мы столкнулись с некоторой загадкой.
У нас был пользователь, который отправил электронное письмо на неверный адрес электронной почты. К сожалению, неправильно указанный домен существует. У него не было записей MX, и запись A домена отправлялась на сервер, который не говорил по SMTP. Таким образом, почтовый сервер попытался доставить доставку, но безуспешно, поскольку почтовый сервер не был запущен.
По этой причине наш почтовый сервер, полностью в соответствии с SMTP RFC, предпринял попытку повторной доставки в течение пяти дней и, наконец, отказался и отправил уведомление отправителю через 5 дней безуспешной доставки.
В разделе 4.5.4.1 RFC5321 (Simple Mail Transfer Protocol) говорится:
Повторные попытки продолжаются до тех пор, пока сообщение не будет передано или отправитель не откажется от него; время отказа обычно должно составлять не менее 4-5 дней.
Таким образом, почтовый сервер в его конфигурации по умолчанию, в этом случае работал в соответствии с RFC, что означает, что пользователь указал неправильный адрес электронной почты адрес в этом случае не получит уведомления об этом, кроме как через пять дней.
В этот момент мой босс спросил, можно ли сократить время отказа до чего-то более короткого, например, до 1 дня. Его аргумент состоит в том, что лучше, чтобы пользователь был уведомлен раньше о недоставке, и что пользователь может попытаться выполнить повторную доставку позднее или доставить через альтернативный канал. Это звучит разумно, но в целом я опасаюсь вносить какие-либо изменения конфигурации, которые противоречат RFC.
Есть ли неочевидная причина, по которой было бы плохой идеей сокращать время отказа до 24 часов, помимо простого заявления «RFC говорит об обратном»?
Кроме того, что делают в этом сценарии более крупные провайдеры электронной почты (Googles, Microsofts, AOL и Yahoos)?
Я не рекомендую изменять время раздачи.Скажем, офис получателя (с электронной почтой на месте) был уничтожен \ торнадо | землетрясением | пожаром \ на выходных. Если компания использует резервные копии на магнитной ленте для своего плана аварийного восстановления, вам лучше поверить, что от торнадо до повторного приема электронной почты потребуется больше 24 часов. В этом случае 5 дней - это слишком долго, но не в этом корень проблемы.
Будь то 5 дней, 48 часов или 24 часа, все эти периоды времени слишком велики для задержки, чтобы получить уведомление об неотправленной электронной почте, и все они слишком короткие, чтобы учесть все возможные причины сбоя сервера. Если вы не используете sendmail, возможно, посмотрите на sendmail, как предлагал MadHatter. По крайней мере, вы должны настроить некоторые оповещения для себя (и / или других), если что-то находится в очереди дольше нескольких часов.
Почему бы вам не отказаться от доставки электронной почты через день? Одна из веских причин - выходные .
Электронная почта сейчас не является и никогда не была, особенно надежной . На заре Интернета, в 80-е годы, электронная почта могла занимать пару дней только для того, чтобы добраться до места назначения, при этом некоторые сетевые ссылки не были круглосуточными, по дорогостоящим междугородним телефонным звонкам (тогда это было стоимость минуты для звонков в два города, не говоря уже о стоимости звонка из Сиднея в Лос-Анджелес), или даже по любительскому радио. В результате доставка электронной почты могла занять некоторое время, а протоколам приходилось справляться с ненадежными соединениями с частичной занятостью. Они делают это очень хорошо, но даже в этом случае почта может задерживаться или теряться.
Конечно, сегодня электронная почта создает иллюзию надежности хотя бы потому, что лежащие в основе механизмы передачи более надежны и многие неосведомленные люди (как и большинство наших пользователей) ) имеют ожидание , что это надежно, но это ожидание не соответствует действительности. Без значительных изменений в протоколах доставки электронной почты, которых, вероятно, никогда не произойдет, электронная почта, как и все, что создано людьми, всегда будет менее чем на 100% идеальным.
Иногда мы, системные администраторы, этим пользуемся.
Например, в офисе, где все только с понедельника по пятницу, я могу отключить электронную почту на все выходные, если это необходимо. Конечно, практически никогда не бывает необходимости отсутствовать так долго, но в редких случаях мне приходилось отключать электронную почту более чем на 24 часа.
В таком случае, если вы откажетесь через 24 часа, электронное письмо будет отправлено в пятницу днем. может не добраться до получателя. Отправитель не узнает до утра понедельника, но если бы вы продолжали попытки, получатель получил бы его к утру понедельника.
Кроме того, очень важно правильно установить ожидания пользователей. Тот факт, что электронная почта в Интернете не является и никогда не будет на 100% надежной, необходимо четко понимать, даже если нам нравится думать, что это так.
RFC говорит, что вы должны продолжать попытки, именно потому что вещи пойти не так, как надо, и предполагается, что в конечном итоге письмо будет доставлено, если возможно, но в какой-то момент вам все же придется отказаться. Можно было бы сократить это до трех дней. Я всегда думал, что пять дней - это слишком долго, чтобы ждать доставки большинства сообщений в круглосуточном Интернете.
Что касается вашего почтового сервера:
Postfix может уведомить отправителей, когда сообщение электронной почты было отложено, но эта функция по умолчанию выключен. Этого предупреждения должно быть достаточно, чтобы ваши пользователи знали, что что-то пошло не так, например, неверный адрес электронной почты, и они придут намного раньше, чем через 24 часа, предложенные вашим начальником.
Чтобы включить его, установите delayed_warning_time на желаемое значение в main.cf .
delayed_warning_time=4h
Начиная с версии 3.0, Postfix может также уведомлять тех же отправителей, когда наконец доставлены задержанные сообщения. Он также отключен по умолчанию, так как может привести к появлению большого количества уведомлений. Но если вы этого хотите, включите confirm_delay_cleared в main.cf .
confirm_delay_cleared=yes
Я собираюсь использовать другую сторону этого вопроса, чем большинство ответов здесь.
Интернет-провайдер, на который я работаю, обслуживает около 3000 клиентов и использует Qmail в качестве нашего MTA для этих клиентов почтовые ящики.
Мы использовали нашу систему с двухдневным сроком службы очереди в течение почти двух лет и не получали никаких жалоб и не имели проблем с доставкой почты. Он уменьшил размер очереди, что значительно упростило обнаружение скомпрометированных учетных записей (редко, но они случаются) и их очистку.
Время жизни очереди в течение дня - это всего лишь системное администрирование Cargo Cult и временное прекращение. Интернет был гораздо менее "всегда включен". Хорошие системные администраторы следуют «лучшим практикам», но даже лучшие понимают, почему они были лучшими, и меняют «лучшие практики» на лучшие, когда ситуация отличается от той, в которой были разработаны предыдущие «лучшие практики».