A Thief on the Run by Manweri
Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом, поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.
Позитивные сдвиги уже есть: с каждым месяцем мы видим прирост числа корпоративных отправителей, прописавших DMARC, на десятки процентов. Однако безусловно, еще есть над чем работать. Практика показывает, что IT-культура находится на очень разном уровне. Кто-то слышал краем уха про DMARC, но пока не собирается его внедрять. Есть и такие, для кого факт, что в транспортных протоколах электронной почты отсутствует какая-либо проверка и защита адреса отправителя, до сих пор является настоящим откровением. Кроме того, поддержка DMARC — задача непростая. Только на первый взгляд кажется, что достаточно опубликовать запись в DNS, и не требуется никакого дополнительного софта или технических средств (подробнее в нашей статье DMARC: защитите вашу рассылку от подделок). На практике в крупной компании с многочисленными потоками электронной почты и развесистой структурой почтовых доменов все гораздо сложнее. И есть моменты, которые следует предусмотреть и продумать заранее. Именно для таких сложных случаев мы написали эту статью, постаравшись собрать в ней все нюансы.
Мы хотим поделиться собственным опытом внедрения DMARC и всеми граблями, на которые мы наступили (зачеркнуто) теми рекомендациями, которые мы выработали при взаимодействии с крупными компаниями и государственными учреждениями. Мы рассмотрим только внедрение политики DMARC для защиты доменного имени. Внедрение серверной части DMARC для защиты пользователей корпоративного почтового сервера от поддельных писем — это отдельный, совершенно самостоятельный и независимый процесс.
DMARC — это политика действий с пришедшими письмами, у которых в поле From используется публикующий политику домен. DMARC позволяет не только указать, как поступать с такими письмами, но и собрать статистику от всех получателей, поддерживающих серверную часть DMARC.
Основной проблемой является то, что DMARC требует авторизации всех легитимных писем. А для этого необходимо не просто внедрить методы авторизации (в качестве базовых протоколов используются SPF и DKIM), но и добиться того, чтобы для всех без исключения легитимных писем с обратными адресами домена проходила авторизация. Поэтому внедрение DMARC стоит начинать с нижеследующего пункта.
1. Проведите ревизию легитимных писем от вашего домена и его поддоменов
Типичные упущения в этом процессе:
- коммерческие письма, отправляемые через внешних поставщиков услуг по рассылке;
- внутренние списки рассылки;
- перенаправления почты с ящиков пользователей;
- технологические письма, формируемые серверами и оборудованием;
- отчеты о доставке (DSN) или о невозможности доставки (NDR) писем.
Для каждой категории писем необходимо внедрить SPF и выяснить возможность или невозможность подписи писем с использованием DKIM.
2. Внедрите SPF для основного домена и его поддоменов
Часто можно услышать, что SPF защищает адрес отправителя от подделки. Это не так. SPF контролирует только адрес SMTP-конверта, который не видит пользователь. При этом большое количество доменов до сих пор не внедрили его, и многие стороны не поддерживают переадресацию почты, совместимую с SPF. По этой причине чаще всего используется нейтральная политика SPF (neutral,
?) или мягкое блокирование (soft reject, ~). Для совместного использования с DMARC не имеет значения, какая именно дефолтная политика (neutral ?, soft reject ~ или reject -) SPF будет использована. Мы не рекомендуем использовать политику reject (-) за исключением особо требовательных к безопасности доменов, так как это может негативно сказаться на доставке легитимных писем непрямыми способами, например через пересылки или списки рассылки. Хотя большая часть получателей не блокирует письма по SPF даже при публикации строгой политики, а использует SPF в рамках весовых классификаторов. Вопреки устоявшемуся мнению, именно такой режим SPF чаще всего применяется на практике, и он полностью соответствует рекомендациям стандарта. Можно дать следующие рекомендации по внедрению SPF:
- Не забывайте, что SPF проверяется для домена из адреса envelope-from (он же MAIL FROM и Return-Path). Для того чтобы SPF можно было использовать для аутентификации отправителя сообщения, домен в envelope-from должен совпадать с доменом заголовка From с точностью до организационного домена (т. е. до домена второго уровня в .ru или .com). Использование неправильных адресов для envelope-from — одна из самых частых ошибок конфигурации сервера, CMS и серверных скриптов.
- В SMTP некоторые категории писем (NDR, DSN) имеют пустой адрес envelope-from. Для таких писем аутентификация производится по домену, который SMTP-сервер отправителя использует в команде HELO/EHLO и который, как правило, совпадает с каноническим именем сервера. Некорректные имена в команде HELO — это еще одна распространенная проблема. Убедитесь, что доменное имя в HELO правильное, и пропишите для него соответствующую SPF политику например,
mailserver.example.org. TXT "v=spf1 a -all". Проверьте, что в сообщениях о невозможности доставки не используется домен или используется домен, совпадающий с доменом HELO с точностью до второго уровня.
- Не забывайте, что SPF не действует на поддомены. Необходимо внедрять его для каждого поддомена или прибегать к wildcards DNS.
- SPF имеет ограничение на 10 разрешений имен для одной записи. Поэтому следует минимизировать использование элементов, приводящих к дополнительным разрешениям, таких как
mxиinclude. Например, для элементаmxтребуется один дополнительный запрос на получение самой MX-записи и по одному запросу на каждый сервер в MX-записи для получения его IP-адреса по имени.
3. Опубликуйте DMARC-запись с политикой none для основного домена и поддоменов
Пример такой записи:
_dmarc.example.com. TXT "v=DMARC1;p=none;rua=mailto:rua@example.com;ruf=mailto:ruf@example.com;fo=s"Запись инструктирует получателя отправлять на адрес
rua@example.com ежедневные статистические отчеты. Из отчетов будут видны все IP-адреса, с которых производилась рассылка писем от имени вашего домена, и статус авторизации SPF, DKIM и DMARC для этих писем. Особенно внимательно следите за письмами с ваших IP-адресов. Проконтролируйте по отчетам, не упустили ли вы какие-то категории писем или их источники в своей ревизии. При необходимости скорректируйте SPF. Некоторые получатели могут слать отчеты по отдельным случаям проблем с SPF (fo=s) на адрес ruf, эти отчеты пригодятся для идентификации проблемных рассылок.Типичные проблемы и рекомендации:
- Мы не советуем публиковать политику даже с тегом
noneдо того, как для основных потоков писем будет внедрен хотя бы один из механизмов аутентификации SPF или DKIM. - Запись должна начинаться именно с v=DMARC1, и регистр букв имеет значение.
- Некоторые клиенты DNS показывают обратные слеши перед точками с запятой
v=DMARC1\;p=none— но в записях DNS-зоны обратный слеш добавлять, как правило, не требуется. - Адреса rua/ruf должны принадлежать тому же организационному домену, для которого публикуется политика, либо принимающий домен должен опубликовать специальную политику, показывающую согласие на прием репортов. Не получится принимать репорты на адреса, например, публичных почт.
- Если вы еще не закончили внедрение DKIM, то вы будете получать достаточно много нарушений DMARC с IP-адресов публичных почт (Mail.Ru, Gmail, Hotmail/Outlook, Yahoo и т. п.). Это связано с тем, что пользователи данных сервисов часто используют перенаправления в другие ящики, и это приводит к нарушению аутентификации SPF. Устраняется проблема внедрением подписи DKIM.
- Есть неплохие инструменты для визуализации отчетов DMARC. Dmarcian предоставляет платные и бесплатные (для небольших объемов почты) сервисы, и удобный удобный бесплатный инструмент XML-To-Human Converter для просмотра DMARC-отчетов. Agari и ReturnPath также предлагают коммерческие сервисы для внедрения и поддержки DMARC.
4. Внедрите DKIM
Рекомендации:
- Убедитесь, что генерируемые серверами письма соответствуют рекомендациям, иначе возможна ситуация, что при передаче почтовым релеем письмо будет изменено для приведения его в соответствие со стандартами (чаще всего происходит разбивка длинных строк), отчего нарушится DKIM-сигнатура.
- Используйте режим канонизации relaxed/relaxed, он реже приводит к проблемам, связанным с нормализацией письма при передаче.
- Внедрите DKIM на всех источниках писем для всех поддоменов.
- Используйте отдельные селекторы с отдельными ключами для внешних источников (провайдеров услуг по рассылке почты), чтобы была возможность отозвать ключ при необходимости.
- Для DMARC необходимо, чтобы домен, используемый в DKIM-подписи, совпадал с точностью до организационного домена с доменом из заголовка From. При этом могут присутствовать и другие DKIM-подписи, но они будут игнорироваться.
- Контролируйте внедрение DKIM по статистическим отчетам от внешних сервисов.
- Используйте
fo=1в политике DMARC, это позволит получать forensic-репорты по всем проблемам с SPF и DKIM, даже для писем, проходящих авторизацию DMARC.
5. Начните переключение на строгую политику
Не используйте подолгу политику quarantine, так как она может маскировать имеющиеся проблемы. Обязательно следите за журналами сервера и отчетами о невозможности доставки писем на предмет ошибок, связанных с DMARC. Стандарт рекомендует получателям, внедряющим серверную часть DMARC, обязательно указывать его как причину в сообщении об ошибке, поэтому для идентификации проблемы можно использовать «DMARC» как ключевое слово в сообщении об ошибке. По журналам сервера вы увидите проблему гораздо раньше, чем по отчетам.
Можно начать с включения политики на 10% (
p=reject; pct=10), чтобы отследить потенциальные проблемы по ошибкам доставки, так как агрегированные репорты приходят только спустя некоторое время. Но долго держать такую политику не рекомендуется: на оставшиеся 90 % срабатываний будет применяться политика quarantine, и можно пропустить единичные проблемы.Можно внедрять политику, отличную от политики основного домена, на отдельные поддомены, публикуя для них отдельные политики или указав в политике основного домена (
p=none; sp=reject): политика sp будет действовать на поддомены, которые не публикуют собственную политику.Когда все поддомены будут переведены на строгую политику, можно убрать политики поддоменов — или же оставить, на ваше усмотрение. Влияет это только на генерацию репортов в соответствии со сложившейся практикой (в стандарте данный момент не обговорен). Если поддомен публикует свою политику, на нее станут приходить отдельные репорты; если отдельной политики нет, то отчеты по поддомену будут включаться в отчет родительского домена.
6. Тюнинг политики DMARC
Ниже приведен разбор некоторых необязательных полей DMARC-записи, примеры и рекомендации по их использованию.
p (
p=reject) — политика DMARC. Указывает получателю, как поступать с письмами, не проходящими аутентификацию. Может принимать значения none (доставлять письма получателю), quarantine (доставлять письма в папку «Спам») и reject (не принимать письма).sp (
sp=quarantine) — политика для поддоменов, не публикующих самостоятельной политики. Если поддомен имеет собственную политику DMARC, то sp на него не влияет. При отсутствии поля sp в записи DMARC для поддоменов, не имеющих собственной политики, применяется политика из поля p.pct (
pct=20) — процент писем, на которые действует данная политика. Например, при задании политики reject с pct=20 к полученному письму с вероятностью 20 % будет применена политика reject и с вероятностью 80 % — политика quarantine.rua (
rua=mailto:ruamailbox@example.com) — адрес, на который получатели будут отправлять аггрегированный (статистический) отчет. Адрес должен принадлежать тому же организационному домену. Мы рекомендуем обязательно публиковать адрес для аггрегированных отчетов и следить за ними как минимум на этапе внедрения политики DMARC.ruf (
ruf=mailto:rufmailbox@example.com) — адрес, на который будут отправляться forensic-отчеты (т. е. исследовательские) по отдельным письмам. По умолчанию forensic-репорты отправляются только по нарушениям DMARC. Можно использовать опцию fo для регулирования поведения. В настоящее время относительно небольшое количество получателей отправляет forensic-отчеты.fo (
fo=1) — по каким нарушениям отправлять уведомления. fo=0 (поведение по умолчанию) отправляет отчеты, только когда не прошли обе аутентификации: SPF и DKIM. fo=1 — когда не проходит любая из аутентификация, даже если проходит альтернативный метод. fo=s шлет forensic-репорты на проблемы с SPF-аутентификаций. fo=d — на проблемы DKIM.adkim (
adkim=r) — режим проверки соответствия DKIM-домена. По умолчанию используется режим r (relaxed) и должен совпадать только организационный домен. В строгом (s) режиме требуется полное совпадение домена из адреса отправителя с доменом из DKIM-сигнатуры. Имеет смысл использовать строгое соответствие домена, если часть ваших поддоменов делегирована недоверенным сторонам.aspf (
aspf=r) — аналогично для домена из envelope-from, для которого проверяется SPF и From. При aspf=s эти домены должны полностью совпадать для прохождения аутентификации SPF.ri (
ri=86400) — желательный интервал получения аггрегированных отчетов (в секундах). По умолчанию отчеты отправляются раз в сутки, но некоторые получатели (не все, т.к. поддержка данного параметра сервером не является обязательной) поддерживают отправку отчетов с более короткими интервалами. На этапе внедрения политики можно попробовать использовать меньшие ri, например ri=3600.Мы очень рады, что владельцы доменов начали задумываться о защите своего доменного имени в электронной переписке. Справку по настройке DMARC можно получить здесь. Если у вас есть вопросы или вам требуются советы либо помощь с настройкой SPF, DKIM, DMARC, обращайтесь по адресу dmarc_support@corp.mail.ru или задайте вопрос здесь. Мы надеемся, что вместе сможем сделать электронную почту безопасней для всех пользователей.
Комментарии (33)
rumkin
22.11.2016 14:17Возможно это офтоп, но… Совершенно недавно окунулся в мир почты. И у меня складывается такое ощущение, что все достижения разработчиков последних десятилетий обошли технологию email стороной. Один плохой дизайн накладывается на другой.
У меня как у пользователя встает один вопрос, когда почтой снова можно будет начать пользоваться? Почему крупные операторы стоят в стороне от прогресса. Когда уже появится какой-нибудь консорциум наподобие whatwg и устранит эту кашу из технологий и осовременит email.
z3apa3a
22.11.2016 14:32+1Это немного неправильные впечатления. E-mail очень активно активно развивается и пользоваться им вполне можно. Текущая версия SMTP (RFC 5321) и формата письма (RFC 5322) — 2008й год, DKIM — 2011й год (RFC 5376), DMARC (RFC 7489) — 2015й год и крупные операторы не просто не стоят в стороне, они как раз и участвуют в разработках этих стандартов. DMARC в той или иной степени, хотя бы в режиме none есть у всех почтовых сервисов.
Проблема в другом. Очень мало кто из администраторов знаком с новыми технологиями почты. 100% администраторов с которыми приходилось общаться уверены, что SPF должен защищать почту от подделок (что абсолютно не соответствует действительности). Как заставить, например, крупные российские банки внедрить SPF, DKIM и DMARC, которых там как правило нет, при том что в штатах DMARC есть практически у всех крупных финансовых организаций? Мы на себя взяли задачу — продвинуть технологию среди администраторов. И уже есть определенные успехи.
kozzztik
22.11.2016 16:04Если у всех финансовых организаций в США он есть, вероятно это прописано в каких то требованиях безопасности и это проверяют при аудите. Надо и нам прописать, тогда и у нас это будет.
rumkin
22.11.2016 17:47DMARC для построения отчетов использует XML, который сегодня уже считается утратившим актуальность. И это при том, что создавался он в 2015! Понимаю, еще если бы это был 2005. Это раз. Два: наличие таких игроков как spamhaus, которые в большей степени паразитируют на слабости технологии перед спам-атаками, говорит об отсутствии на рынке общей стратегии по дальнейшему развитию.
Далее идет низкая насыщенность программными решениями: большинство присутствующих сегодня продуктов имеют слабую поддержку сообщества и имеют высокий порог входа. Из-за чего важные нововведения проходят со скрипом.
Как заставить, например, крупные российские банки внедрить SPF, DKIM и DMARC,
… а обновления требуется заставлять внедрять. Не потому ли, что дорого!? Сама технология почты очень дорогая в обслуживании. Сегодня почта живет на почтовых гигантах и корпоративном сегменте. Устоявшееся мнение, что почту проще доверить яндексу или гуглу является нормой. И, даже потеря конфиденциальности, никого не останавливает. Нет, с почтой у нас определенно проблемы.
z3apa3a
22.11.2016 18:20+1Во-первых, почему это XML утратил актуальность? XML тяжеловесный стандарт, поэтому для AJAX может быть и выгодней JSON, но у JSON есть проблемы реализаций из-за недостаточно четких стандартов и отсутствует язык описания схем, у YAML или BSON вообще нет стандартизации какой-либо признанной организацией. У XML есть язык описания схемы и он разрабатывается W3C, что позволяет его использовать в стандартах. Мне XML на текущий момент кажется единственным возможным вариантом.
Во-вторых спецификация DMARC позволяет расширять форматы и добавить другие методы при необходимости.
amarao
22.11.2016 14:50Проблема в том, что как только кто-то решает осовременить почту, она тут же становится проприетарным решением конкретной компании. (hello winmail.dat).
Вся сила почты в том, что из-за своей универсальности и всеобщести она заставляет всех подстраиваться под неё. Хорошо или плохо, но это много лучше, чем любая альтернативная система, придуманная компаниями.
Я могу написать пользователю microsoft и пользователю apple, даже если один из них пользуется skype, а другой viber'ом, и даже если рядом есть фанат блекберри с watsup'ом, то он может написать харкорному пользователю hipchat'а.
Посредством электронной почты, разумеется.rumkin
22.11.2016 17:49Я о том, что консорциум браузеров появился, а консорциум почтовых клиентов – нет. Что, согласитесь, странно для второй по значимости технологии интернета. При этом почта до сих пор страдает детскими болезнями первородного Интернета.
z3apa3a
22.11.2016 18:27+1Это совсем не так. W3C занимается стандартизацией HTML и связанных стандартов. Стандартизацией почтовых протоколов и стандартов занимается IETF, где есть несколько рабочих групп. Например, прямо сейчас идет очень активная работа в рабочих группах ietf-dkim/ietf-dmarc, где обсуждается расширение DKIM для защиты от replay-атак и внедрение ARC а в рабочей группе ietf-dane, например, обсуждается SMTP STS.
amarao
22.11.2016 19:32+1Если честно, то это браузеры страдают болезнями детства. Например, мне недавно намертво сломали доступ к железкам с SSL3. Да, я знаю, что не секьюрно. На момент выпуска железки было секьюрно, сейчас нет. Ну и работайте с ним как с HTTP. Но нет, нельзя подключиться. Даже exception'а нет. Приходится юзать файрфокс 3 в отдельной виртуалке. Почтовый клиент, не способный разобрать письмо от другого почтового клиента 2010 года производства, просто бы спустили в утиль. Ибо совместимость. А браузерам и их консорциумам позволено творить что попало и ломать совместимость со старыми системами к чертям.
LoadRunner
23.11.2016 08:48С iLO на серверах HP та же картина — приходится ставить firefox 2.0 и java 5_11, чтобы быть уверенным, что всё заведётся.
rumkin
23.11.2016 11:51Чтобы не заморачиваться с FF под виртуалкой удобнее использовать HTTP-туннель, а то как-то ну совсем уж хардкорно.
amarao
23.11.2016 12:01Там ещё старая java нужна, так что оно в целом — ужасно. Виртуалка менее геморрно, чем поддержание неактуальных версий софта на рабочей машине.
kozzztik
22.11.2016 16:07Проблема в том, что ее никто не разрабатывал. По сути стандарт это некая попытка привести к единому знаменателю уже имевшиеся на тот момент практики, читай костыли которые каждый втыкал как умел. При этом нужно понимать что выходит новая версия стандарта, а старые сервера со старыми реализациями никуда не деваются. Плюс куча сомнительного софта написанного как попало для отправки почты, куча клиентов которые реализуют свою сторону как хотят, полная анархия.
В итоге реализуя почтовый протокол нужно думать не только о стандарте, но и о всем многообразии отступлений от него.rumkin
22.11.2016 17:55Дизайн протокола как абсолютно распределенного обмена сообщениями очень хорош. Но методы защиты и представления информации остались на зачаточном уровне. При этом проблема продолжает потреблять большие деньги.
Устаревшие почтовые клиенты и сервера, могут бесконечно долго успешно существовать, пока не сложится предпосылок для замен, так можно еще пару десятилетий протянуть. А обратную совместимость при внесении изменений никто не отменял. Чтобы не попасть в проприетарную ловушку нужно объединять усилия сообщества разработчиков, тогда ситуация поменяется в лучшую сторону очень быстро.
kozzztik
22.11.2016 19:45Так собственно RFC и есть результат объединения усилий разработчиков. Не сказал бы что ситуация меняется в лучшую сторону очень быстро )
Проблема защиты упирается по сути в основном в масштабы. Это я говорю как разработчик системы защиты почты если что. Есть невероятно много источников почты, которые настроены как попало, с каким попало софтом и шлют всякую дрянь. И эта дрянь является легитимной почтой, ее нельзя просто взять и выкинуть. Единственная реальная возможность продвигать стандарты безопасности — это быть монополистом с сильной политической волей. Как например гугл хром. Отжать львиную долю рынка и тупо отключить поддержку небезопасных сертификатов. Иначе весь интернет не заставить. К сожалению в области почты нет такого крупного монополиста, которым мог это сделать.z3apa3a
23.11.2016 00:31На самом деле то же самое происходит и в почте, хотя и не настолько очевидно. Yahoo и AOL дали толчок DMARCу, без них он остался бы мертвым стандартом, а Google и Microsoft сейчас сильно завинчивают гайки для писем без аутентификации отправителя.
LoadRunner
22.11.2016 15:07Удобная возможность спросить: в чём может быть причина неудачного перенаправления сообщения с корпоративного ящика на почтовый ящик mail.ru? Причём не всех писем, малая часть всё же перенаправляется успешно.
Подпись DKIM внедрена и проблем с ней не наблюдается.z3apa3a
22.11.2016 15:16А накопительное обновление 6 стоит? Если да, то покажите полный текст сообщения о невозможности доставки (с заголовками исходного сообщения), можно в личку.
LoadRunner
22.11.2016 15:29Обновления ставятся регулярно. CU14 установлен.
Вас интересует всё письмо целиком или диагностические сообщения, которые сервер вставляет в тело письма?
past
22.11.2016 15:22Скажите, кто-нибудь нашел нормальный инструмент для обработки DMARC отчетов?
z3apa3a
22.11.2016 15:30В статье есть немного рекомендаций по этому поводу.
Для отдельных отчетов можно использовать https://dmarcian.com/dmarc-xml/
для организации процесса обработки в целом удобно использовать либо сервис, который тот же Dmarcian представляет по подписке (есть бесплатные подписки для небольших объемов почты) либо его аналоги. Мы пользуемся услугами Agari.
Бесплатных готовых инструментов пока не встречалось.
LoadRunner
22.11.2016 15:30DMARC стандартизирован, можно писать свой велосипед. Но указанный в статье Dmarcian вполне подходит для небольшой организации.
dronmaxman
22.11.2016 18:51+1Для себя пользуем такой костыль: https://github.com/techsneeze/dmarcts-report-viewer
TerAnYu
24.11.2016 21:59Возможно https://www.mail-tester.com/ будет полезен при настройке почтовых отправлений. Подсказывает что необходимо сделать с вашей стороны.
mxms
Хорошее дело но не без изъянов.
В настоящее время наблюдаются проблемы с политикой DMARC типа reject в случае использования сервера пересылки (backup MX) и при работе с листами рассылки (mailing list). Поэтому я бы рекомендовал не увлекаться закручиванием гаек, удовлетворившись пока политикой quarantine.
z3apa3a
Пересылка обычно работает без проблем при наличии DKIM-подписи в письме. Проблемы встречаются, например в Hotmail/Outlook т.к. на части пересылаемых писем бьется DKIM, что приводит к нарушению DMARC, Microsoft обещает эту проблему устранить. Аналогичная проблема есть в устаревших и уже не поддерживаемых версиях Exchange.
Со списками рассылки действительно бывают проблемы, но большая часть крупных списков уже умеют обнаруживать домены с DMARC и делать для них замену From. Строгий DMARC уже есть у yahoo.com, aol.com, mail.ru, Microsoft обещал внедрить на outlook/hotmail до конца года, GMail так же анонсировал внедрение, поэтому списки рассылки вынуждены адаптироваться. Если это действительно необходимо, можно выделить отдельный поддомен с более мягкой политикой специально для постинга в списки рассылки.
mxms
Пересылка работает, в основном, но всегда, к сожалению.
А по спискам рассылки вообще красивого решения нет.