Фон

У нас есть работа веб-приложения 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"

Наша проблема состоит в том, что, для получения возвращенных сообщений (хотя просто так, чтобы они могли затем быть отброшены), мы думаем что также:

1. webapp.example.com должен выполнить сервер SMTP, который принимает возвращенные сообщения;

2. некоторая другая машина должна выполнить сервер SMTP, который принимает возвращенные сообщения, и запись MX должна быть добавлена к webapp.example.com. так, чтобы они были поставлены туда; или

3. обратный канал должен быть изменен, например, на webapp@example.com— в этом случае не только должен, что диспетчеры почты домена принимают возвращенные сообщения, но и, также, также:

   (a) политика отправителя для получающегося домена, например. example.com., должен быть обновлен для включения a:webapp.example.com; или

   (b) веб-приложение должно передать все исходящие сообщения через хосты, утвержденные политикой отправителя того домена, например. 192.0.2.0/24.

Проблемы

Опция № 1 является нежелательным, потому что мы особенно не хотим дополнительное воздействие безопасности выполнения дополнительного общедоступного сервиса на машину, которая размещает веб-приложение (меньше всего тот, который выполняет так мало).

Опция № 2 является нежелательным, потому что наш единственный общедоступный mailservice обеспечивается третьим лицом, и создание новых доменов получателя выходит за рамки нашего существующего соглашения о предоставлении услуг.

Опция № 3 (a) является нежелательным, потому что мы не хотим предоставлять webapp.example.com разрешение породить сообщения из других отправителей в example.com.

Опция № 3 (b) является нежелательным, потому что это повлекло бы за собой поддержание соединения VPN от (общедоступного) webapp.example.com к нашей безопасной, внутренней единственной сети.

Таким образом, что мы должны сделать?

Опция № 2 Perhaps была бы лучшим решением во многих случаях. Однако в свете причин, приведенных выше, для нас, опция № 1 выглядит меньше всего плохо — все же все еще похоже на огромное излишество. Существует ли лучший путь?