Регистрация...

Почтовый сервер Eserv // DMARC

wikipost // (v3)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
Новости
15.05.2012
Eserv504
15.05.2012
ActiveSync
01.04.2012
Eproxy508
25.03.2012
Eserv503
26.02.2012
Eserv502
08.02.2012
UMI.CMS
22.12.2011
Eserv431
20.12.2011
Eproxy507
15.11.2011
Eproxy506
19.09.2011
Eproxy505
08.09.2011
Eserv430
06.09.2011
Lightning
19.07.2011
PoweredBy
16.07.2011
IPv6
08.07.2011
Eproxy5beta1
17.06.2011
IPv6DNS
13.06.2011
IPv6Mail
21.03.2011
Eserv428
22.10.2010
Eserv426
22.10.2010
SSL
22.04.2010
Eserv423
20.04.2010
Eserv4WhatsNew
19.04.2010
EservLDAP
19.04.2010
EservDHCP
19.04.2010
EservRubricator
08.04.2010
EservDNS
08.04.2010
NSСI
08.04.2010
WPAD
27.03.2010
Eserv422
27.03.2010
Eserv4Docs
26.03.2010
Eserv4FAQ
21.03.2010
EservIrc
05.03.2010
Eserv421
05.03.2010
HttpProxy
02.03.2010
EservVideo
02.12.2009
Eserv4Wiki
02.12.2009
Eserv4acWEB
02.12.2009
PopPull
22.11.2009
PigMailPigProxy2/WhatsNew
22.11.2009
PigMail/WhatsNew
22.09.2009
FossilEservHowTo
22.09.2009
SourceCodeManagement
22.09.2009
FossilScm
16.09.2009
SendEmail
08.09.2009
RoundCube
07.05.2009
GitScm
07.05.2009
GitEservHowTo
06.05.2009
SunBird
06.05.2009
WebDav
20.04.2009
Etelnet

DMARC

http://dmarc.org/
http://dmarc.org/overview.html
http://dmarc.org/draft-dmarc-base-00-01.html
http://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 — ну, кроме сбора указанной статистики про активных экспериментаторов, конечно

DMARC author-to-recipient flow
 
Комментарии к версии 1 (06.02.2012 02:08) [~support] 53a6e1a7
Комментарии к версии 2 (06.02.2012 02:28) [~support] 76c30385
Комментарии к этой версии (06.02.2012 02:46) [~support] 202b4cd0
Работает на Eserv/5.05555 (05.06.2016)