Бетке Сергей: iT блог

Приведу краткую информацию о существующих либо существовавших технологиях подтверждения подлинности отправителя.

• SPF (Sender Policy Framework). Определена в RFC 4408.
  Проверка результата внедрения:
  http://www.myiptest.com/staticpages/index.php/DomainKeys-DKIM-SPF-Validator-test-rez
  http://www.kitterman.com/spf/validate.html
  http://tools.bevhost.com/spf/
  Рекомендую к обязательному внедрению на ЛЮБОМ ДОМЕНЕ, даже и не принимающем почту. 
  http://www.openspf.org/, хорошо и понятно о синтаксе SPF — http://www.openspf.org/SPF_Record_Syntax.
  Замечательные средства проверки spf: http://www.openspf.org/Tools. Мне понравился вариант с письмом в адрес <mailto:check-auth@verifier.port25.com>. Проверяет сразу несколько технологий идентификации. Ещё один замечательный тест http://www.winserver.com/public/antispam/testwcsap.wct
  Рекомендации и частые ошибки http://www.openspf.org/FAQ/Common_mistakes. В частности:
  *    Если заголовок HELO отличается от имени домена, для него должна быть своя spf
  *    Для каждого FQDN следует указать spf. Внесём эти записи в наши домены.
  Удобный COM Объект для контроля spf и не только http://www.aloaha.com/download/spfdns.txt.
• VERP (Variable Envelope Return Path)
• BATV (Bounce Address Tag Validation)  проверка обратного адреса  — только проект, но неплохой, надо сказать… Очень неплохая идея, надо сказать, с точки зрения совместимости с MTA, не поддерживающими данную технологию. Более чем интересная. Есть уже реализация от MS: Forefront Protection 2010 . Так что для поддержки данной технологии исключительно средствами MS необходимо переходить на Microsoft Exchange Server 2010 +  ForeFront 2010. Exchange требуется не ниже 2007.
• DKIM (RFC 4871, RFC 5585). Тесты http://domainkeys.sourceforge.net/. Эта технология не поддерживается на текущий момент MS, и, видимо, – и не планируется (http://technet.microsoft.com/en-us/magazine/2006.12.sidf.aspx). Поддержка необходимых типов записей DNS обеспечена только с Microsoft Windows 2008 Server.
  Реализация для exchange: http://www.emailarchitect.net/domainkeys/ (платная)
• CLEAR (Compatible Low-level Email Authentication and Responsibility)  — включает в себя BATV и  CSV (Certified Server Validation).
• Sender ID – также рекомендую добавить политики в каждый Ваш домен, для этого требуется только желание.
• SRS (Sender Rewriting Scheme)  — для "пересыльщиков" почты в связи с вводом SPF один из вариантов решения. Хотя сейчас уже найдено иное решение — spf2.0/pra и отправка behalf on. Предшественник – RPR (Return Path Rewriting).
• TECS (Trusted Email Connection Signing) — подпись сессии. Не суждено, я думаю, жить этому проекту.
  Данная технология — ещё один шаг в сторону DKIM, SMTP+TLS. Но — он проще в плане внедрения и распространения. И вот почему. Этот вариант не требует шифрования письма, он просто подразумевает подпись сессии, точнее — авторизацию сессии через цифровую подпись. По сути, подобный механизм может быть реализован на уровне sink к любому действующему smtp, и не требует изменения всей прочей инфраструктуры, что хорошо. Но, должен признаться, область применения схожа с областью применения spf и sender-id, кто бы и что ни говорил. Да, последние завязаны на ip адреса, но политики могут быть изменены, и они не требуют вообще доработки MTA.
  И технология spf + urlbl способна дать репутационный сервис по доменам, к чему и tecs подводит — отвязаться от Ip адресов. Честно говоря, не вижу, чтобы tecs был чем то шире spf. И проблемы, кстати, ровно те же (с пересылкой).
• RMX (Reverse MX) — прадедушка SPF.
• MXOUT — Соглашение об DNS именовании MTA. По сути, данная технология с успехом и полностью может быть заменена SPF. 
  По этому проекту наш MTA должен был представляться в HELO server-12.mxout.novgaro.ru (при этом mxout.novgaro.ru будет недопустимым). При этом в dns зоне:
          mxout    IN    A  127.0.0.x (в нашем случае целесообразно 127.0.0.3)
          Server-12.mxout IN A <ip адрес> (следует прочитать про допустимость CNAME вместо A).
  *    127.0.0.1 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers."
  *    127.0.0.2 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention."
  *    127.0.0.3 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail having an envelope-from of this base domain, if the connection is from a server using any base domain which does not conform to the .mxout. convention."
  *    127.0.0.4 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail from our authorized servers if the envelope-from domain does not share a name server host with this domain."
  *    127.0.0.5 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail claiming to be from this base domain, if the connection is from a server using any base domain which does not conform to the .mxout. convention. In addition, please reject mail from our authorized servers if the envelope-from domain does not share a name server with this domain."
  *    127.0.0.6 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail with an envelope-from of this base domain, if the connection is from a server using any base domain other than this one."
  *    127.0.0.7 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail with an envelope-from of this base domain, if the connection is from a server using any base domain other than this one. In addition, please reject mail from our authorized servers if the envelope-from domain does not share a name server with this domain.
  По сути, технология прекрасно заменена SPF. И явно не будет жизнеспособной. Опять-таки, в состоянии проверить только HELO заголовок, не более.
• CSV/CSA (Certified Server Validation)  — http://mipassoc.org/csv/csa-finch.html http://wiki.fastmail.fm/index.php?title=Certified_Server_Validation. http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.html. Так же альтернатива SPF. И также можем без проблем поддержать эту технологию. 
  По этому проекту наш MTA может представляться HELO novgaro.ru — без проблем:
  В зоне novgaro.ru:
          _client._smtp SRV 1 2 1 mx.novgaro.ru
  По сути, технология прекрасно заменена SPF. В принципе, нам ничего не мешает поддержать и эту технологию.
  Если наш сервер будет представляться как server-12.novgaro.ru, тогда потребуется следующая запись:
          _client._smtp.server-12 SRV 1 2 1 mx.novgaro.ru
  Однако, технология крайне дурная. По сути, она позволяет проверить только HELO заголовок — сопоставить заголовок и ip адрес сервера, не более. Проверить авторизацию сервера на отправку почты домена — нет возможности. Поэтому можно забыть про эту технологию.
• DNA (Domain Name Accreditation) — решение с построение dns репутационных сервисов ip-домен сторонними сервисами по отношению к домену отправителя.
• AMTP — замена SMTP протокола. Очень неплохое будущее у этого проекта на первый взгляд… SMTP + TLS + сертификаты + некое MPC расширение smtp + srv записи. Будем ждать реализации… (http://support.microsoft.com/kb/829721, http://amtp.bw.org/docs/draft-weinman-amtp-03.txt, http://tools.ietf.org/html/draft-crouzet-amtp-01)
  По сути, предлагается обычный SMTP, но работающий исключительно поверх TLS. Только поверх TLS. Отличия от SMTP:
  *    Требует обязательно TLS
  *    Сервер получатель определяется через DNS, но не через A или MX записи, а через запрос к SRV записи:
                  amtp.tcp.domain.com.           SRV    10 0 25    mx.domain.com.
                  Надо уточнить, будут ли _ перед amtp и tcp… приоритет, вес и порт — по своим назначениям.
  Безусловно, очень логичное применение srv зап
  исей. Как раз — строго по назначению. И с приоритетами всё понятно, и со сменой портов.
  *    Дополнительные ограничения на HELO: The PTR RR MUST match the Subject field of the client MTA’s X.509 certificate, and MUST also match the host name in the EHLO argument that the client MTA presents to the server MTA. В принципе — всё ясно. Но этот шаг пока позволяет только проверить тот факт, что MTA себя правильно представляет, а не тот факт, что он имеет права слать от имени домена отправителя…
  *    HELO команда более не поддерживается (ответ 504), только EHLO
  *    На EHLO ответ 504, если не соответствует сертификату.
  *    Ответ принимающей стороны обязан сообщать о поддержке MPC (mail policy code) (здесь всё подробно расписано с примерами).
  *    MTA обязан добавить MPC параметр к глаголу MAIL (и схожим по функциям).
  *    Принимающий сервер обязан включить объявленный отправителем MPC в заголовок письма MPC: значение.
  Как описано выше в статье ms, уже сейчас можно требовать и использовать TLS. Однако — без дополнительных ограничений AMTP, приведённых выше.
• MARID — рабочая группа по авторизации MTA через DNS.

Ссылка на замечательный документ, объединяющий множество технологий сразу . И в этом документе я также вижу рекомендации по созданию spf записей для каждого fqdn в DNS зоне.

Буду благодарен за любые комментарии и дополнения. Постарался собрать все технологии идентификации отправителя, которые были, есть или будут.