У нас есть веб-приложение, работающее на webapp.example.com который (среди прочего) время от времени отправляет сообщения по электронной почте. Эти сообщения не являются критическими: хотя мы хотели бы приложить максимум усилий для их доставки, знание о том, что доставка сообщения не удалась, не представляет интереса.
Имея это в виду, вчера я спросил Что делать, если вы не хотите получать сообщения о недоставке писем?- к сожалению, кажется, что ответ - отказаться от таких отскоков после сначала получать их (а не отказываться от них, например, на уровне SMTP или ниже; или передавать исходные сообщения с нулевым обратным путем).
Предположим, что сообщения, сгенерированные веб-приложением, в настоящее время имеют обратный путь webservice@webapp.example.com а в DNS домен example.com. полностью определяется следующими записями:
@ SOA ns.example.net. hostmaster 1 86400 7200 604800 300
NS ns.example.net.
NS ns.example.org.
MX 1 mx.example.net.
TXT "v=spf1 a:192.0.2.0/24 -all"
webapp A 198.51.100.1
TXT "v=spf1 a -all"
Наша проблема в том, что для получения сообщений об отказе (хотя и чисто для того, чтобы потом их можно было выбросить), мы думаем, что либо:
webapp.example.com должен запустить SMTP-сервер, который принимает рикошеты;
на другом компьютере должен быть запущен SMTP-сервер, который принимает сообщения о недоставке, а запись MX должна быть добавлена в webapp.example.com. чтобы они были доставлены туда; или
обратный путь должен быть изменен, например к webapp@example.com- в этом случае почтовые обменники этого домена должны не только принимать сообщения о недоставке, но также:
(а) политика отправителя для результирующего домена, например example.com., необходимо обновить, чтобы включить a:webapp.example.com; или
(b) веб-приложение должно ретранслировать все исходящие сообщения через хосты, одобренные политикой отправителя этого домена, например 192.0.2.0/24.
Вариант №1 нежелателен, потому что мы не особенно хотим дополнительной уязвимости безопасности, связанной с запуском дополнительной общедоступной службы на машине, на которой размещено веб-приложение (по крайней мере, той, которая так мало выполняет).
Вариант № 2 нежелателен, потому что наша единственная общедоступная почтовая служба предоставляется третьей стороной, а создание новых доменов получателей выходит за рамки нашего существующего соглашения о предоставлении услуг.
Вариант № 3 (а) нежелателен, потому что мы не желаем предоставлять webapp.example.com разрешение на отправку сообщений от других отправителей в пределах example.com.
Вариант № 3 (б) нежелателен, поскольку он повлечет за собой поддержание VPN-соединения с (общедоступной) webapp.example.com в нашу безопасную внутреннюю сеть.
так что нам делать?
Возможно, во многих случаях вариант №2 будет лучшим решением. Однако в свете причин, указанных выше, для нас вариант №1 выглядит наименее плохим, но все же кажется огромным излишеством. Есть ли способ лучше?
Читая вашу предыдущую ветку вопросов, я понимаю, что вы используете exim. Я предлагаю настроить его как MTA только для отправки. Я лично использовал это руководство для быстрой настройки почтовых серверов только для отправки в общедоступных сетях. В основном он отказывается от внешних подключений к порту smtp.
Знаю, что это не самый «стандартный» способ решения вопроса, но очень практичный.
Обратной стороной является то, что некоторым поставщикам электронной почты может не понравиться невозможность обратной связи с исходным сервером, и они вообще отказываются принимать почту от него. По моему опыту, я никогда не видел, чтобы такое происходило, но полагаю, это зависит от количества «некритических» писем, которые вы отправляете, и от того, как часто эти письма возвращаются.