Допустим, у моих пользователей есть учетные записи на каком-то почтовом сервере mail.example.com. В настоящее время моя запись mx установлена на mail.example.com, и все в порядке. Теперь предположим, что я хочу, чтобы письма изначально доставлялись во внешнюю службу (например, Postini. Обратите внимание, что это не вопрос, связанный с postini).
В нормальной ситуации, когда мой mx настроен непосредственно на мой почтовый сервер mail.example.com, отправка MTA, конечно, будет искать мой MX и отправлять на mail.example.com. В моей новой ситуации я бы установил мой mx на mx.othermailservice.com, и электронные письма будут приходить туда. OtherEmailService.com затем будет ретранслировать электронные письма (сохраняя тот же заголовок обратного пути) на mail.example.com. Электронные письма, полученные на mail.example.com после ретрансляции от другой службы, «выглядят» иначе, чем электронные письма, которые идут непосредственно к нему, как это было бы в случае, если бы mx был установлен на mail.example.com?
Это зависит от того, как вы определяете «внешний вид». Если вы говорите о том, выглядят ли они иначе с точки зрения клиента, например, с точки зрения перспективы, ответ - нет, они выглядят одинаково.
Главное, что вы заметите, это то, что в этих письмах разные заголовки, очевидно, что они проходят через новую систему, и вы также можете увидеть новые заголовки спама. В некоторых случаях сообщения могут выглядеть по-другому, поскольку в них может быть добавлен тег внизу с надписью «здесь сканировано по имени службы».
Так что это зависит от службы, но особенно с postini конечный пользователь не заметит изменений.
Есть два ключевых отличия таких маршрутизируемых писем от писем, полученных напрямую:
Received-By: заголовок в нем из почтовика-ретранслятора.Первый момент имеет решающее значение, когда дело доходит до защиты от спама, поскольку многие технологии AS сосредоточены на отбрасывании электронной почты, приходящей не откуда (см. Также SPF) или исходящей с IP-адресов, которые выглядят забавно (IP-репутация). Если вы получаете ретрансляцию, ваши AS-системы не должны рассматривать IP-адрес как часть своей проверки.
Это работает так:
Если бы это был Интернет примерно в 1992 году, это не было бы проблемой. Тогда было более доверительное время, и в этом случае mailer.example.yourcorp с радостью примет сообщение, и никто не станет мудрее.
Спам бросает сюда гаечный ключ. На этом этапе служба защиты от спама, работающая непосредственно на mailer.example.yourcorp, может подорвать. Поскольку в SPF-записи example.client (например) не указано, что example.antispam является авторизованным почтовым отправителем, он может сбросить сообщение на пол, чтобы его больше никогда не видели.
Службы защиты от спама работают лучше всего, когда они работают в почтовой программе, которая напрямую принимает почту из Интернета. Это в значительной степени связано с тем, что службы репутации IP были одной из лучших технологий защиты от спама, и чтобы использовать ее, вам необходимо увидеть эти TCP-соединения. Спрячьтесь за почтовый ретранслятор, и вы потеряете это преимущество.
Второй момент - добавление протокола к заголовкам почты, требуемым стандартами SMTP. Клиент никогда не должен замечать.