SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.
Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.
TL;DR — рекомендации в конце.
1. Заблуждение: SPF защищает мой домен от подделок
На самом деле: SPF никак не защищает видимый пользователю адрес отправителя.
Объяснение: SPF вообще не работает с содержимым письма, которое видит пользователь, в частности с адресом отправителя. SPF авторизует и проверяет адреса на уровне почтового транспорта (SMTP) между двумя MTA (envelope-from, RFC5321.MailFrom aka Return-Path). Эти адреса не видны пользователю и могут отличаться от видимых пользователю адресов из заголовка From письма (RFC5322.From). Таким образом, письмо с поддельным отправителем во From запросто может пройти SPF-авторизацию.
2. Заблуждение: Я внедрю SPF и станет безопасней и меньше спама
На самом деле: скорей всего, изменений в плане безопасности и спама вы не заметите.
Объяснение: SPF изначально альтруистический протокол и сам по себе не дает преимуществ тому, кто публикует SPF-политику. Теоретически, внедрение вами SPF могло бы защитить кого-то другого от поддельных писем с вашего домена. Но на практике даже это не так, потому что результаты SPF редко используются напрямую (об этом ниже). Боле того, даже если бы все домены публиковали SPF, а все получатели запрещали получение писем без SPF-авторизации, это вряд ли привело бы к снижению уровня спама.
SPF не защищает от подделки отправителя или спама напрямую, тем не менее, он активно используется и весьма полезен и в системах спам-фильтрации и для защиты от поддельных писем, т.к. позволяет привязать письмо к определенному домену и его репутации.
3. Заблуждение: SPF отрицательно (положительно) влияет на доставляемость писем
На самом деле: Всё зависит от типа письма и пути, по которому оно доставляется.
Объяснение: SPF сам по себе не влияет на доставляемость писем обычным потоком, и отрицательно влияет при неправильном внедрении или на непрямых потоках писем (indirect flow), когда пользователь получает письма не от того сервера, с которого письмо было отправлено, например на перенаправленные письма. Но системы спам-фильтрации и репутационные классификаторы учитывают наличие SPF, что в целом, на основном потоке писем, дает положительный результат. Если, конечно, вы не рассылаете спам.
4. Заблуждение: SPF авторизует отправителя письма
На самом деле: SPF авторизует почтовый сервер, отправляющий письмо от имени домена.
Объяснение: Во-первых, SPF работает только на уровне доменов, а не для отдельных адресов электронной почты. Во-вторых, даже если вы являетесь легальным пользователем почты определенного домена, SPF не позволяет вам отправить письмо из любого места. Чтобы письмо прошло SPF-валидацию, вы должны отправлять только через авторизованный сервер. В-третьих, если вы авторизовали сервер по SPF (например, разрешили отправку писем от вашего домена через какого-либо ESP или хостинг-провайдера) и он не реализует дополнительных ограничений, то все пользователи данного сервера могут рассылать письма от имени вашего домена. Всё это следует учитывать при внедрении SPF и аутентификации писем в целом.
5. Заблуждение: письма, не прошедшие авторизацию SPF, отсеиваются
На самом деле: SPF-авторизация или ее отсутствие в общем случае не влияет кардинально на доставку писем.
Объяснение: стандарт SPF является только стандартом авторизации и в явном виде указывает, что действия, применяемые к письмам, не прошедшим авторизацию, находятся за пределами стандарта и определяются локальной политикой получателя. Отказ в получении таких писем приводит к проблемам с письмами, идущими через непрямые маршруты доставки, например, перенаправления или списки рассылки, и этот факт должен учитываться в локальной политике. На практике, строгий отказ из-за сбоя SPF-авторизации не рекомендуется к использованию и возможен только при публикации доменом политики -all (hardfail) в отсутствии других средств фильтрации. В большинстве случаев, SPF-авторизация используется как один из признаков в классификаторах или как один из факторов в весовых системах. Причем вес этого фактора очень небольшой, потому что нарушение SPF-авторизации обычно не является сколь-либо достоверным признаком спама — многие спам-письма проходят SPF-авторизацию, а вполне легальные — нет, и вряд ли эта ситуация когда-нибудь кардинально изменится. При таком использовании, разницы между -all и ~all нет.
Факт наличия SPF-авторизации важен не столько для доставки письма и принятия решения о том, является ли оно спамом, сколько для подтверждения адреса отправителя и связи с доменом, что позволяет для письма использовать не репутацию IP, а репутацию домена.
На принятие решения о действии над письмом, не прошедшим авторизацию, гораздо больше влияет политика DMARC. Политика DMARC позволяет отбросить (или поместить в карантин) все письма, не прошедшие авторизацию или их процент.
6. Заблуждение: в SPF надо использовать -all (hardfail), это безопасней чем ?all или ~all
На самом деле: на практике -all никак не влияет ни на чью безопасность, зато негативно влияет на доставляемость писем.
Объяснение: -all приводит к блокировке писем, отправленных через непрямые маршруты теми немногими получателями, которые используют результат SPF напрямую и блокируют письма. При этом на большую часть спама и поддельных писем эта политика существенного влияния не окажет. На текущий момент наиболее разумной политикой считается ~all (softfail), она используется практически всеми крупными доменам, даже теми, у которых очень высокие требованиями к безопасности (paypal.com, например). -all можно использовать для доменов, с которых не производится отправки легальных писем. Для DMARC -, ~ и ? являются эквивалентными.
7. Заблуждение: достаточно прописать SPF только для доменов, с которых отправляется почта
На самом деле: необходимо также прописать SPF для доменов, используемых в HELO почтовых серверов, и желательно прописать блокирующую политику для неиспользуемых для отправки почты A-записей и вайлдкарда.
Объяснение: в некоторых случаях, в частности, при доставке NDR (сообщение о невозможности доставки), DSN (сообщение подтверждения доставки) и некоторых автоответах, адрес отправителя в SMTP-конверте (envelope-from) является пустым. В таком случае SPF проверяет имя хоста из команды HELO/EHLO. Необходимо проверить, какое имя используется в данной команде (например, заглянув в конфигурацию сервера или отправив письмо на публичный сервер и посмотрев заголовки) и прописать для него SPF. Спамерам совершенно не обязательно слать спам с тех же доменов, с которых вы отправляете письма, они могут отправлять от имени любого хоста, имеющего A- или MX-запись. Поэтому, если вы публикуете SPF из альтруистических соображений, то надо добавлять SPF для всех таких записей, и желательно еще wildcard (*) для несуществующих записей.
8. Заблуждение: лучше добавлять в DNS запись специального типа SPF, а не TXT
На самом деле: надо добавлять запись типа TXT.
Объяснение: в текущей версии стандарта SPF (RFC 7208) записи типа SPF являются deprecated и не должны больше использоваться.
9. Заблуждение: чем больше всего (a, mx, ptr, include) я включу в SPF-запись, тем лучше, потому что меньше вероятность ошибиться
На самом деле: по возможности, следует максимально сократить SPF-запись и использовать в ней только адреса сетей через ip4/ip6.
Объяснение: на разрешение SPF-политики отведен лимит в 10 DNS-запросов. Его превышение приведет к постоянной ошибке политики (permerror). Кроме того, DNS является ненадежной службой, и для каждого запроса есть вероятность сбоя (temperror), которая возрастает с количеством запросов. Каждая дополнительная запись a или include требует дополнительного DNS-запроса, для include также необходимо запросить всё, что указано в include-записи. mx требует запроса MX-записей и дополнительного запроса A-записи для каждого MX-сервера. ptr требует дополнительного запроса, к тому же в принципе является небезопасной. Только адреса сетей, перечисленные через ip4/ip6, не требуют дополнительных DNS-запросов.
10. Заблуждение: TTL для SPF-записи следует сделать поменьше (побольше)
На самом деле: как и для большинства DNS-записей, лучше иметь TTL в диапазоне от 1 часа до 1 суток, заблаговременно снижая его при внедрении или планируемых изменениях и повышая при стабильно работающей политике.
Объяснение: более высокий TTL снижает вероятность ошибок DNS и, как следствие, temperror SPF, но повышает время реакции при необходимости внесения изменений в SPF-запись.
11. Заблуждение: если я не знаю, с каких IP могут уходить мои письма, то лучше опубликовать политику с +all
На самом деле: политика с явным +all или неявным правилом, разрешающим рассылку от имени домена с любых IP-адресов, негативно скажется на доставке почты.
Объяснение: такая политика не несет смысловой нагрузки и часто используется спамерами, чтобы обеспечить SPF-аутентификацию на спам-письмах, рассылаемых через ботнеты. Поэтому домен, публикующий подобную политику, имеет очень большие шансы попасть под блокировку.
12. Заблуждение: SPF бесполезен
На самом деле: SPF необходим.
Объяснение: SPF — это один из механизмов авторизации отправителя в электронной почте и способ идентификации домена в репутационных системах. В настоящее время крупные провайдеры почтовых сервисов постепенно начинают требовать наличие авторизации писем, и на письма, не имеющие авторизации, могут накладываться «штрафные санкции» по их доставке или отображению пользователю. Кроме того, на письма, не прошедшие SPF-авторизации, могут не возвращаться автоответы и отчеты о доставке или невозможности доставки. Причина в том, что эти категории ответов, как правило, идут именно на адрес SMTP-конверта и требуют, чтобы он был авторизован. Поэтому SPF необходим даже в том случае, если все письма авторизованы DKIM. Также SPF совершенно необходим в IPv6-сетях и облачных сервисах: в таких сетях практически невозможно использовать репутацию IP-адреса и письма с адресов, не авторизованных SPF, как правило, не принимаются. Одна из основных задач SPF, определенная в стандарте — как раз использование репутации доменного имени вместо репутации IP.
13. Заблуждение: SPF самодостаточен
На самом деле: необходимы также DKIM и DMARC.
Объяснение: DKIM необходим для прохождения писем через различные пересылки. DMARC необходим для защиты адреса отправителя от подделок. Кроме того, DMARC позволяет получать отчеты о нарушениях политики SPF.
14. Заблуждение: одна SPF-запись — хорошо, а две — лучше
На самом деле: запись должна быть ровно одна.
Объяснение: это требование стандарта. Если записей будет более одной, это приведет к постоянной ошибке (permerror). Если необходимо объединить несколько SPF-записей, опубликуйте запись с несколькими include.
15. Заблуждение: spf1 хорошо, spf2.0 — лучше
На самом деле: надо использовать v=spf1.
Объяснение: spf2.0 не существует. Публикация записи spf2.0 может приводить к непредсказуемым результатам. spf2.0 никогда не существовал и не был стандартом, но отсылка на него есть в серии экспериментальных стандартов, самым известным из которых является RFC 4406 (Sender ID). Эта серия стандартов разрабатывалась независимой рабочей группой, параллельно с принятием стандарта spf, что и внесло путаницу. Sender ID, который должен был решить проблему подмены адресов, не стал общепринятым стандартом и от него следует отказаться в пользу DMARC. Даже в том случае, если вы решаете использовать Sender ID и опубликовать spf2.0 запись, она не заменит записи spf1.
Я практически закончил писать эту статью, когда меня перехватила служба поддержки пользователей и настоятельно (с угрозой применения грубой силы) рекомендовала напомнить о следующих нюансах SPF, с которыми им чаще всего приходится сталкиваться при разрешении проблем:
- SPF-политика должна заканчиваться директивой
allилиredirect. После этих директив ничего идти не должно. - Директивы
allилиredirectмогут встретиться в политике ровно один раз, они заменяют друг друга (то есть в одной политике не может бытьallиredirectодновременно). - Директива
includeне заменяет директивыallилиredirect.includeможет встретиться в политике несколько раз, при этом политику всё равно следует завершать директивамиallилиredirect. Политика, включаемая черезincludeилиredirect, также должна быть валидной политикой, оканчивающейся на директивуallилиredirect. При этом дляincludeбезразлично, какое правило (-all,~all,?all) используется дляallво включаемой политике, а дляredirectразница есть. - Директива
includeиспользуется с двоеточием (include:example.com), директиваredirect— со знаком равенства (redirect=example.com). - SPF не распространяется на поддомены. SPF. Не. Распространяется. На. Поддомены. SPF НЕ РАСПРОСТРАНЯЕТСЯ НА ПОДДОМЕНЫ. (а DMARC, по умолчанию, распространяется). Надо публиковать SPF для каждой записи A или MX в DNS, по которой производится (или может производиться) доставка почты.
Резюме
- Обязательно создайте политику для всех MX- и, желательно, A-записей.
- Добавьте SPF-политики для имен, используемых в HELO/EHLO почтового сервера.
- Публикуйте SPF-политику как TXT-запись с
v=spf1в DNS. - В политике преимущественно используйте адреса сетей заданные через
ip4/ip6. Располагайте их в начале политики, чтобы избежать лишних DNS-запросов. Минимизируйте использованиеinclude, не используйте без необходимостиa, без крайней и непреодолимой необходимости не используйтеmxи никогда не используйтеptr. - Указывайте
~allдля доменов, с которых реально отправляются письма,-all— для неиспользуемых доменов и записей. - Используйте маленькие TTL на период внедрения и тестирования, затем повысьте TTL до разумных значений. Заблаговременно снижайте TTL при необходимости внесения изменений.
- Обязательно тестируйте правильность SPF-политики, например, здесь.
- Не ограничивайтесь только SPF, постарайтесь внедрить DKIM и обязательно внедрите DMARC. DMARC поможет защитить ваши письма от подделок и позволит вам получать информацию по нарушениям SPF. Это позволит выявить подделки, непрямые потоки писем и ошибки конфигурации.
- После внедрения SPF, DKIM и/или DMARC проверьте их с помощью сервиса https://postmaster.mail.ru/security/.
SPF и DMARC проверяются по текущему состоянию, наличие DKIM проверяется по статистическим данным за предыдущий день и будет показываться только при наличии переписки с ящиками на Mail.Ru в предшествующий день или ранее.
Пример политики SPF: @ IN TXT "v=spf1 ip4:1.2.3.0/24 include:_spf.myesp.example.com ~all"
Комментарии (22)
qwertyRu
26.09.2017 14:01z3apa3a пишу Вам, может донесете до поддержки (на запрос поддержка не ответила)
Если Вы не можете ни как донести или ответить, можете отклонить комментарий.
У вас есть сервис postmaster, к нему подключен домен, и все рекомендации выполнены. Согласно статистики postmaster спама нет, но по логам почтового сервера спама где то 10%.
Почему получаются разные данные?
z3apa3a Автор
26.09.2017 14:05+1В статистике Postmaster@ отображаются только письма, имеющие DKIM-авторизацию вашего домена, независимо от того, с какого адреса они были отправлены, возможно, что не принимаемые письма не имеют DKIM подписи или она некорректна, это же может быть и причиной их классификации как спама.
Но лучше отправить информацию, включая логи на адрес postmaster@corp.mail.ru.
pda0
26.09.2017 14:16Не, тут бы более подробный разбор бы не помешал. Допустим есть домен example.com в качестве «письменного», т.е. user@example.com. Сервер на mail.example.com, прописан в MX.
Получаем:
example.com. IN TXT "v=spf1 mx a ~all"
Получается нужна ещё:
*.example.com. IN TXT "v=spf1 -all"
Или для mx делается отдельная разрешающая?z3apa3a Автор
26.09.2017 14:36+2Все еще сложнее. В идеале, если у вас есть зона, например:
example.com. IN MX 10 mail.example.com.
example.com. IN A 1.2.3.4
mail.example.com. IN A 1.2.3.5
www.example.com. IN A 1.2.3.4
Сервер mail.example.com имеет каноническое имя mail.example.com и сконфигурирован использовать его в команде HELO. Тогда нужны следующие записи:
; основная SPF-запись
example.com. IN TXT "v=spf1 mx a ~all"
; SPF-запись для HELO
mail.example.com. IN TXT "v=spf1 a -all"
; SPF-запись экранирующая www.example.com (при условии что это имя не каноническое и не используется в HELO)
www.example.com. IN TXT "v=spf1 -all"
; экранирующий SPF-wildcard
*.example.com. IN TXT "v=spf1 -all"
совсем в идеале вместо
example.com. IN TXT "v=spf1 mx a ~all"
лучше использовать
example.com. IN TXT "v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 ~all"pda0
26.09.2017 14:42А почему одна экранирующая wildcard запись не покрывает mail и www?
z3apa3a Автор
26.09.2017 14:45+4Так работают вайлдкарды в большинстве DNS-серверов — вайлдкард возвращается только если нет записи с таким именем любого типа. Если не сделать отдельную экранирующую запись для www, то запрос TXT-записи www.example.com. вернет 0 записей данного типа даже при наличии вайлдкарда, потому что есть A-запись www.example.com.
Для mail.example.com нужна разрешающая запись, которая разрешит серверу mail.example.com использовать это имя в команде HELO.
achekalin
26.09.2017 18:15+1Самое страшное — когда получатель почты, какая-нибудь серьезная компания, типа банка, не принимает почту от твоего сервера, ссылаясь на то, что они (выбрать по вкусу) считают контент спамом / используют кривой RBL / в твоем SPF нашли что-то, чего не поняли / попробовали проверить DKIM, и не осилили — и письмо вместо чем принять, и пометить как «возможно спам», просто не берут. А твой, скажем, главбух не может до банка дописаться — и материт всех.
И банк этот, считая, что у них все секурно, а) никогда не сменит политику «просто так», и б) не оставляет никакого вариант отправить им письмо. Ну как никакого — с gmail то же самое до дих дойдет успешно.
И никакого шанса достучаться до них и сказать — парни, вы бы свой сетап проверили, что ли — нет.z3apa3a Автор
26.09.2017 18:39+2Да, такая проблема есть. По стандартам, для этих целей должен быть работающий адрес postmaster@ или abuse@, вы можете попробоваться связаться по ним. Ответ сервера 5xx так же может содержать информацию (например URI) с контактами для решения проблемы. Но, к сожалению, на практике postmaster@ часто не работает или работает, но никем не читается.
Вообще любая автоматическая фильтрация почты это зло, но реальность такова, что спам составляет более 90% писем. Отказываться от автоматической фильтрации значит перекладывать фильтрацию на пользователя, и это не вариант, т.к. пользователь ошибается нисколько не реже (может удалить или засунуть в папку спама нужное письмо). Кроме того, 15 минут рабочего времени в день, потраченные на разбор спама это итоговые потери, сравнимые с потерями по больничным листам. Поэтому надеяться, что кто-то откажется от спам-фильтрации, не стоит.
Есть лайфхак: как правило, банки (и не только) очень внимательно мониторят соц. сети, вы можете попробовать донести информацию там, добавив правильные теги. Но не забывайте, что ваша задача решить конкретную проблему, а не обидеться или высказать претензию :) совместное решение проблемы будет позитивным откликом и для вас и для банка.
achekalin
27.09.2017 09:55+3Когда работающая для людей компания не принимает от людей почту — это как-то неправильно.
Банки часто консервативны, потому что неотключение идиотского фильтра — это по инструкции, и сотрудника не накажут, а отключение — это мало-ли-что. И перебороть это слабо получается. Даже критика в соцсетях тут странно выглядит, пока PR передаст проблему, пока технари разберутся, пока напишут и согласуют ответ «мы работаем ради безопасности ваших денег, а вы, раз так, злобные спаммеры!» — проще банк сменить.
Mendel
29.09.2017 11:35Банки в соцсетях отвечают очень быстро, но если это не простая задача, то ответ их будет столь же бесполезен как и любой другой способ связи. Т.е. — не могу достучаться === они передадут ваше письмо. А вот «почините спамфильтр» будет «мы работаем над этим». Через год напомните, и будет «все еще работаем».
vagonovozhaty
27.09.2017 01:20Есть хороший сервис для DMARC, dmarcian.com.
Там все отчеты по каждому домену, в удобном виде, с графиками и т.д.
Temmokan
27.09.2017 05:17> Боле того, даже если бы все домены публиковали SPF, а все получатели запрещали получение писем без SPF-авторизации, это вряд ли привело бы к снижению уровня спама
Может, поясните широким народным массам, почему? Большинство спамерских писем с поддельными адресами отправителя не пройдут проверку SPF.
На практике полагаться на успех или неуспех проверки SPF нет смысла только потому, что у ощутимого количества легитимных отправителей до сих пор толком не настроены средства аутентификации (SPF, DKIM, DMARC и т.д.)z3apa3a Автор
27.09.2017 10:55+1Потому что сейчас стоимость регистрации какого-нибудь домена $0, домена в приличной зоне — $2-3. Стоимость хостинга DNS $0. Поэтому в спаме все чаще используются не подменные адреса, а свежие домены с нулевой историей, которые регистрируются под одну рассылку, причем рассылки проводятся очень быстро (за время порядка 5 минут) с высокой интенсивностью. На таких рассылках может быть и SPF и DKIM и DMARC.
С точки зрения современных антиспам-систем это одно и то же — что на письмах с отсутствующей авторизацией, что на письмах с доменов без истории нельзя использовать репутацию домена и работают другие классификаторы и как правило эти рассылки не создают проблем. А вот для фильтров по SPF, DNSBL, простых сигнатурных антиспам-систем и т.п. такие рассылки часто «невидимы».Temmokan
27.09.2017 11:25Нулевой домен, без истории легитимных писем — в greylist. Не самое элегантное решение, но вполне действующее с не очень большими потерями.
О своём: судя по статистике спама, приходящего на корпоративные адреса, нулевых доменов там минимум. В основном старый приём — вставка случайных адресов, которые одним SPF режутся на раз.z3apa3a Автор
27.09.2017 12:32Если у спамера нет задачи реально доставить письма — то поможет все что угодно. Мы по статистике DMARC до сих пор видим миллионные рассылки, которые реально доходят только до единичных ящиков, на которых вообще нет спам-фильтров, потому что DMARC в отличие от SPF дает возможность строго фильтровать поддельные письма.
Против качественного спама грейлистинг сам по себе не спасет, вы просто получите спам на несколько минут позднее, если вы не умеете выделять рассылки, их классифицировать и накапливать репутацию по отдельным рассылкам. Грейлистинг используется чтобы накопить информацию о рассылке и ее классифицировать.
То что вы не видите «качественного» спама скорей всего означает, что на вас его еще не таргетировали, и вы просто неуловимый Джо.Temmokan
27.09.2017 14:44Ну, не всё так просто — совокупно спама к нам сыплется до 200 писем в сутки на ящик, а строго фильтровать его затруднительно: когда должны доходить сообщения на адрес той же тех.поддержки, особо не пошикуешь. У клиентов в настройках аутентификации доменов обычно творится тихий ужас, и строгая фильтрация по DMARC (т.е., по итогам проверок DKIM/SPF) многие такие письма убила бы в зародыше. «Низзя!».
Фильтрация спама — занятие затейливое, решаем комплексно, естественно. В целом ситуация приемлемая.
Кроме того, в данной ситуации быть Неуловимым Джо на редкость приятно.
nekipelov
Спасибо за полезную информацию! В среди аббревиатур DMARC, DKIM и SPF не хватает ARC. Очень интересно, планирует ли почта mail.ru внедрение Authenticated Received Chain (http://arc-spec.org/)?
z3apa3a Автор
ARC еще не принят в качестве стандарта и мы активно участвуем в его обсуждении и разработке в рамках M3AAWG и IETF. Пока наша позиция в основном критическая — дело в том, что ARC фактически является заменой вайтлистов по DKIM, при этом он критикуется за избыточное использование криптографии (там где она бесполезна или не требуется для решения задач).
Если кратко — основные проблемы ARC в том, что
1. он требует установления доверия ко всей подписывающей цепочке. Каких-либо способов установления такого доверия сам стандарт не дает. Это планируется решать за счет включения модерируемого списка «доверенных» форвардеров в основные продукты, поддерживающие ARC. По этой причине ARC мало кому помогает и не является полноценной замной используемых сейчас списков доверенных форвардеров и совсем никак не помогает администраторам небольшого списка рассылки, например — т.к. алгоритм попадания в публикуемые списки не известен, а без него ARC бесполезен.
2. Используемый алгоритм цепочки подписей в ARC бесполезен, т.к. нужен для транзитивного доверия (как в цепочке сертификатов, например), которого в ARC нет, поэтому вся эта цепочка не имеет смысла, было бы достаточно только подписи последнего
хоста в цепочке.
3. ARC добавляет очень много информации к заголовкам сообщений. Это может привести к проблемам во многих MTA, где есть ограничения на размер заголовка.
Но, разумеется, если ARC будет внедрен и будет поддерживаться основными MTA/менеджерами списков рассылки, мы так же реализуем его поддержку.
z3apa3a Автор
Кстати, на днях опубликовали вот такой драфт по Lenient DKIM:
www.ietf.org/id/draft-vanrein-dkim-lenient-00.txt
Мысль гораздо правильней чем ARC, она позволяет отследить какие изменения были внесены в подписанное письмо. Но боюсь, что в реальности ARC будет принят, а Lenient DKIM нет, т.к. за ARC'ом стоят бородатые стандартописатели.