DMARC
http://dmarc.org/http://dmarc.org/overview.htmlhttp://dmarc.org/draft-dmarc-base-00-01.htmlhttp://www.returnpath.net/commercialsender/domainassurance/dmarc/
Очередная попытка (после SenderPolicyFramework и YahooDomainKeys/DKIM ) предложить механизм реализации почтовой политики домена. Не смотря на заявления о том, что в разработке спецификации принимали участие Yahoo и Google (активные пользователи указанных выше технологий, а Yahoo еще и изобретатель доменных ключей, лежащих в основе YDK/DKIM), на практике спецификация разработана компанией Cloudmark. Как обычно при "смене коней" преемственность идеологии хромает, а в данном случае автор вообще плохо знаком с технологиями, которые он предлагает улучшить, и демонстрирует совсем плохое знакомство с сопутствующими технологиями...
Единственная "новая" идея, предлагаемая авторами многостраничной спецификации — предложение публикации в DNS (в "_dmark.почтовый_домен" TXT-записях) email-адресов, на которые должны отправляться извещения в случаях, если получатель (MX-сервер) отвергает или задерживает письмо.
На первый взгляд идея неплохая, т.к. дает (должен давать) способ публикации официального адреса почтовой администрации домена (который обычно имеет вид postmaster@домен или abuse@домен, но предположим, что мы этого не знаем
вдобавок к известным путям публикации доменной администрации (в SOA-записях и в WHOIS). Но на второй взгляд идея плохая, т.к., во-первых, порождает дополнительный почтовый поток (который не факт, что будет принят) в стиле "переписка роботов" (никто же в здравом уме не предположит, что все эти многомилионные новые "отлупы" будут читать новые специально нанятые отряды живых людей), а во-вторых, уже десятилетия для тех же целей (получения уведомлений о недоставке на спец.адрес, указание точной причины недоставки) используется более эффективный метод, не приводящий к новым кросс-серверным письмам и не выходящие за рамки спецификации SMTP: принимающий MX может указать (и обычно указывает) причину недоставки почты в расшифровках SMTP-кодов ответов (в 5xx и 4xx, выдаваемых при отказах и задержках), а отправляющий MTA при получении таких ответов может (и по стандарту и должен) вернуть письмо отправителю (с пояснениями о причинах неудачной доставки, в т.ч. с цитатой ответа принимающего MX), и ничто ему не мешает отправить копию такого письма и на тот самый "спец.адрес" почтовой администрации — ему не требуется выковыривать этот адрес из _dmarc-записей, он этот адрес и сам знает (адрес своей собственной администрации); а если отлупы предполагаются и на промежуточных серверах, то адрес для отлупов можно прямо в SMTP MAILFROM указывать (что тоже давным-давно делается теми почтовыми службами, которым важен более детальный контроль доставки).
В рекламе также указывается, что крупнейшие почтовые серверы — Yahoo, MS Hotmail, Google, LinkedIn, Facebook, PayPal, eBay, и т.д. уже вовсю используют указанную технологию. Это не так. На сегодняшний день (6 февраля 2012) DMARC-записи отсутствуют в Gmail, Google, Yahoo, Hotmail, Microsoft. У Facebook, LinkedIn и PayPal есть, но ведут либо на тех же postmaster@, либо на различные ящики домена authmetrics.com. В первом случае (postmaster) очевидно используется прежняя инфраструктура, во втором видимо собирается общая статистика об early adopters этой dmarc-идеи. Если authmetrics.com заметит рост интереса к этой технологии, то возможно эксперимент продолжат. Но с большой вероятностью инициатива уйдёт "в стол", как и все пост-DKIM'ные предложения за последние несколько лет. На мой взгляд нет ни одной веской причины применения DMARC — ну, кроме сбора указанной статистики про активных экспериментаторов, конечно
