У нас есть почтовый сервер для нескольких клиентов, и недавно мы столкнулись с некоторой загадкой.
У нас был пользователь, который отправил электронное письмо на неправильный адрес электронной почты. К сожалению, неправильно указанный домен существует. У него не было записей MX, и запись A домена отправлялась на сервер, который не говорил по SMTP. Таким образом, почтовый сервер попытался доставить письмо, но безуспешно, потому что почтовый сервер не работал.
По этой причине наш почтовый сервер, полностью в соответствии с SMTP RFC, предпринял попытку повторной доставки в течение пяти дней, но в конце концов отказался и отправил уведомление отправителю после 5 дней неудачной доставки.
Раздел 4.5.4.1 RFC5321 (простой протокол передачи почты) говорит:
Повторные попытки продолжаются до тех пор, пока сообщение не будет отправлено или отправитель не откажется от него; время отказа обычно должно составлять не менее 4-5 дней.
Следовательно, почтовый сервер в его конфигурации по умолчанию в этом случае работал в соответствии с RFC, а это означает, что пользователь, указавший неправильный адрес электронной почты в этом случае, не получит уведомления об этом, за исключением пяти дней спустя.
На этом этапе мой босс спросил, можно ли сократить время отказа до чего-то более короткого, например, до 1 дня. Его аргумент состоит в том, что лучше, чтобы пользователь был уведомлен о недоставке раньше, и что пользователь может попытаться повторно доставить его позже или доставить через альтернативный канал. Это звучит разумно, но в целом я с осторожностью отношусь к любым изменениям конфигурации, которые противоречат RFC.
Есть ли какая-то неочевидная причина, по которой было бы плохой идеей сократить время отказа до 24 часов, помимо простого заявления «RFC говорит иное»?
Кроме того, что делают в этом сценарии крупные провайдеры электронной почты (Google, Microsoft, AOL и Yahoos)?
Почему бы вам не отказаться от доставки электронной почты через день? Одна веская причина - выходные.
Электронной почты нет и никогда не было, особенно надежный. На заре Интернета, в 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 и пережиток того времени, когда Интернет был гораздо менее «всегда включен». Хорошие системные администраторы следуют «лучшим практикам», но даже лучшие понимают, почему они были лучшими, и меняют «лучшие практики» на лучшие, когда ситуация отличается от той, в которой были разработаны предыдущие «лучшие практики».
Я не рекомендую менять время раздачи. Скажем, офис получателя (с электронной почтой на месте) был уничтожен \ торнадо | землетрясением | пожаром \ за выходные. Если компания использует резервные копии на магнитной ленте для своего плана аварийного восстановления, вам лучше поверить, что от торнадо до повторного приема электронной почты потребуется больше 24 часов. В этом случае 5 дней было бы слишком долго, но не в этом корень проблемы.
Будь то 5 дней, 48 часов или 24 часа, все эти периоды времени слишком велики для задержки, чтобы получить уведомление об неотправленной электронной почте, и все они слишком короткие, чтобы учесть все возможные причины сбоя сервера. Если вы не используете sendmail, возможно, посмотрите на sendmail, как предлагал MadHatter. По крайней мере, вы должны настроить некоторые оповещения для себя (и / или других), если что-то находится в очереди дольше нескольких часов.