RFC 5321 §4.5.5 состояния:
Все другие типы сообщений (т. Е. Любое сообщение, которое не требует от Standards-Track RFC иметь нулевой обратный путь) ДОЛЖНЫ быть отправлены с действительным ненулевым обратным путем.
Чтобы избежать сомнений, RFC 2119 §3 определяет "ДОЛЖЕН" так как "в определенных обстоятельствах могут существовать веские причины для игнорирования конкретного пункта, но все последствия должны быть поняты и тщательно взвешены, прежде чем выбирать другой курс."
Рассматриваются «особые обстоятельства», в которых Алиса не желает получать уведомления о статусе доставки (связанные с электронными письмами, которые она отправила).
У нее есть несколько вариантов:
игнорировать / отклонять любые такие уведомления, когда она их получает- очевидно, такое поведение было бы совершенно правильным, но это неприятность (и трата ее ресурсов);
отказываться принимать такие уведомления на более низком уровне- возможно, обратный путь больше не будет «действительным» (к сожалению, не определен в RFC), и если да, то такое поведение противоречит рекомендациям RFC; или
создать электронное письмо с нулевым обратным путем, чтобы уведомления никогда не создавались в первую очередь- явно противоречащие рекомендациям RFC.
Я почти уверен, что эти обстоятельства представляют собой «вескую причину» игнорировать приведенную выше рекомендацию RFC, но я хочу быть уверен, что я понял «все последствия» вариантов 2 и 3.
В частности, отмечу, что:
В варианте 2 некоторые агенты могут обнаружить, что обратный путь недействителен.
В варианте 3 некоторые агенты могут рассматривать письма с нулевым обратным путем как особые случаи.
В любом случае, агенты могут отказать в приеме / ретрансляции / доставке электронного письма или могут использовать такую информацию для увеличения вероятности того, что оно будет помечено как спам. Насколько распространены такие меры на практике?
Есть ли другие проблемы / последствия, которые мне следует учесть?
Как правило, лучший подход состоит в том, чтобы передать сообщение о недоставке в какой-то процесс обработки отказов, чтобы адрес получателя, который постоянно отскакивал, можно было удалить из базы данных. Это может быть .forward для "alice" или настройка отправителя конверта в качестве обработчика.
Независимо от того, заботится ли «Алиса» о том, возвращается ли электронное письмо, администраторы сервера получателя или фильтры часто это делают. Во многих случаях серверы-получатели засчитывают каждый отказ как очки отрицательной репутации. Сделайте это достаточно, и вы попадете в их черные списки, и вы не сможете ничего пройти.
Не пожирайте ресурсы других людей, потому что вам лень справиться с этим самостоятельно.
Вариант №1 всегда является лучшим решением. Думайте об этом как о бумажной почте; действующий обратный адрес является обязательным. Электронная почта становится все более ограниченной (DMARC и т. Д.) Из-за того, что спамеры используют открытую политику. На самом деле не так сложно автоматизировать работу с ответами, которые вам не нужны. Но, вероятно, менее 10% почтовых серверов имеют такие ограничения, поэтому вам, вероятно, это сойдет с рук. Также убедитесь, что ваш сервер не указан в dnsbl.
В большинстве случаев правила нестрогие (я могу отправить электронное письмо, которое выглядит так, как будто оно от вас, которое вызовет что-то вроде DDOS, если я отправлю его всем и настрою для отскока). Посмотрите на все ограничения в Постфикс если вы хотите знать, какие правила могут действовать.
Вы не можете получить и то, и другое; сделайте это правильно (№1) или откажитесь от того, чтобы быть отмеченным как спаммер (по крайней мере, некоторыми). Google использует no-reply@google.com, и он никогда не дойдет до меня, потому что моему почтовому серверу требуется проверено отправитель. Google лучше всех борется со спамом, если у них не может быть обоих способов, я уверен, что мы не можем.
В целом, я согласен с тем, что №1, вероятно, лучшее решение, вы можете просто отказаться от любых возвратов на сервере. Установите .forward, который отправляет сообщения в / dev / null. Маловероятно, что ваш счет за пропускную способность повредит.
Что касается более широкого обсуждения того, следует ли вам заботиться о том, чтобы сообщения не доставлялись, я действительно не знаю кого-либо, кто обрабатывает свои собственные возвраты в любом масштабе, но такие службы, как SendGrid, MailGun и т. Д., Отлично справляются с этим, они позволяют вам отправляют через HTTP POST, они управляют репутацией IP-пространства и сообщают вам о возвращенных письмах и жалобах.
Для вашего случая это может быть не ключевым, но в целом я стараюсь в наши дни избегать управления собственной доставкой почты в производственной среде. Так много всего может пойти не так, и это может сильно отвлекать от других аспектов поддержки большого веб-стека.