Postmaster, abuse и прочие *master для наших доменов: поддерживаем RFC2142 на MS Exchange 2003
Буквально пару слов скажу о том, каким путём обеспечил поддержку всех “рекомендованных” RFC адресов для всех своих доменов на MS Exchange 2003. И поговорим немного о RFC2142.
Итак, начинаем с зоны. Приведу пример одной своей mail-enabled зоны (уже приводил в статье “SPF и Sender-ID”).
hostmaster
“Основная” зона:
; ; Database file novgaro.ru.dns for novgaro.ru zone. ; @ 345600 IN SOA ns.novgaro.ru. hostmaster.novgaro.ru. ( 2010102903 ; serial number 7200 ; refresh 120 ; retry 1209600 ; expire 3600 ) ; minimum TTL hostmaster IN RP hostmaster.novgaro.ru. hostmaster.novgaro.ru. IN TXT ( "IT department of GARO group." "" "+7 (816 2) 940969" "" "hostmaster@novgaro.ru" ) ; ; Zone NS records ; @ 345600 IN NS ns.natm.ru. @ 345600 IN NS ns.novgaro.ru. ns 345600 IN A 213.148.164.198 IN TXT ( "v=spf1 -all" ) ; ; Zone records ; @ IN A 213.148.164.198 gate IN A 213.148.164.198 IN TXT ( "v=spf1 -all" ) ; spf subzone _spf IN NS ns.novgaro.ru. ; ; mail services ; mx IN A 213.148.164.198 IN TXT ( "v=spf1 +a -all" ) @ IN MX 10 mx.novgaro.ru. @ IN TXT ( "v=spf1 redirect=_spf.novgaro.ru" ) @ IN TXT ( "spf2.0/mfrom,pra redirect=_spf.novgaro.ru" ) _client._smtp IN SRV 1 2 1 mx.novgaro.ru. ; ; other services ; mail IN CNAME gate.novgaro.ru.
Эту зону привёл ради того, чтобы показать, как и где прописывается hostmaster@ (не следует выдумывать других аналогов, hostmaster рекомендован RFC2142 “Mailbox names for common services, roles and functions”). Как видно, в первую очередь контактные координаты мы должны указать в SOA записи зоны (RFC1033, RFC1034 раздел 3.3, RFC1912 раздел 2.2, Recommendations for DNS SOA Values). И здесь есть тонкости:
- во-первых, вместо hostmaster@novgaro.ru мы должны писать hostmaster.novgaro.ru, вместо sergey.s.betke@novgaro.ru – sergey\.s\.betke.novgaro.ru. Настоятельно рекомендую ограничиться hostmaster;
- если существует RP запись (RFC1183) с FQDN, указанным в SOA записи (в нашем случае – hostmaster.novgaro.ru), тогда реальные контактные координаты следует искать в RP записи. И такой вариант является рекомендуемым, так как в RP записи Вы можете дополнительно указать FQDN TXT записи, содержащей дополнительную контактную информацию (как в моём примере выше);
- RP записей с одним и тем же FQDN может быть несколько. В этом случае при поиске контакта следует анализировать все RP записи с FQDN, указанным в SOA записи.
Обеспечить приём почты на hostmaster@ мало, его в зоне в первую очередь прописать следует :-).
P.S. И при регистрации зоны указывайте пожалуйста для whois тот же hostmaster@, а не какой-нибудь vasya\.pupkin.superdomen.ru. Вася Пупкин завтра уйдёт, а контактные координаты во whois поменять забудут – классика, блин.
P.S. Обращаю внимание на наличие spf политик для всех A записей зоны.
postmaster, abuse
Если Ваша зона mail-enabled (от её имени планируется доставка почты и приём почты), Вы должны обеспечить поддержку ящиков postmaster@, abuse@ (не следует выдумывать других аналогов, указанные рекомендованы RFC2142 “Mailbox names for common services, roles and functions”, RFC822). Для этих адресов необходимы только манипуляции на Exchange (о них дальше).
webmaster, www, ftp, noc, security, usenet, news и прочие
Прочие адреса следует поддерживать, если Вы через Вашу зону публикуете соответствующие сервисы (www и webmaster для http://, fpt для ftp:// и так далее). В соответствии с RFC2142 “Mailbox names for common services, roles and functions”).
Поддержка силами MS Exchange Server множества доменов
Вернёмся, наконец-то, к теме статьи. Исходим из того, что у нас очень много зон и мы можем забыть для всех этих зоны добавить или убрать тот или иной “стандартный” адрес. Попробуем в некоторой степени помочь себе и частично автоматизировать создание необходимых адресов для всех зон.
В первую очередь создадим необходимые группы распространения в AD (на рисунке справа представлена иерархия OU). Я иду следующим путём: для внешних контактов создаю группу рассылки (distribution group) с одним и тем display name и cn – Подписка. Но раскладываю их в разные OU. При таком подходе проще и фильтры в ldap запросах в дальнейшем строить (по cn например), и скриптами проще обрабатывать.
Для каждого “стандартного” адреса я создал OU и группу в нём. Учитывая тот факт, что в моём случае на все вопросы отвечают одни и те же лица, во все эти группы входит в качестве члена группа Подписка выше по уровню, в которую уже включена группа системных инженеров. Плюс подобного подхода очевиден: сменили персонал, изменили только членство в группе системных инженеров, все остальные сервисы (в том числе и обсуждаемые) трогать в принципе нет необходимости.
Далее для каждой группы корректируем атрибуты alias и displayName на странице Exchange General. Для группы postmaster@ указываем алиас postmaster и так далее. На странице Email Addresses не забываем установить атрибут “Automaticaly update e-mail addresses based on recipient policy”. Адреса, которые Вы видите на рисунке, руками в каждую группу вводить не надо, далее покажу как это избежать без программирования.
Теперь создаём в ESM новую Recipient Policy. Модифицируем ldap фильтр:
(& (| (mailnicName=*master) (sAMAccountName=ГРНД ИТ-Администраторы*) ) (objectCategory=group) )
Как говорит один мой коллега, “мировой запас скобок при программировании на lisp катастрофически быстро заканчивается”. То же самое можно сказать и о ldap синтаксисе :-).
Как видно, я выбираю группы, для которых установил алиас в виде *master (postmaster, webmaster, hostmaster и так далее). Но не только их. Также выбираю всех остальные, именованные (не displayName, а sAMAccountName (в диалоге ADAC представлено как “Group name (pre-Windows 2000)”)) как ГРНД ИТ-Администраторы*. И при создании я так и именовал группы: ГРНД ИТ-Администраторы-Почта, ГРНД ИТ-Администраторы-Почта-О спаме и так далее. С ldap фильтром, я думаю, разобрались.
Настала пора вернуться к созданной нами Recipient Policy. На странице E-Mail Addresses при появлении новых доменов мы должны добавить новый адрес, нажав кнопку New и введя "@домен.рф”. После чего нажимаем Apply и Yes. И через некоторое время в созданных нами выше группах получаем адреса для всех доменов, которые мы прописали в созданной нами политике.
Вот так вот всё просто.
P.S. Обратите внимание на “странный” на первый взгляд шаблон smtp адреса – "@[213.148.164.198]”. В Вашем случае – будут Ваши ip адреса. Вы должны обеспечить приём на адрес abuse@[213.148.164.198] (в моём случае) в соответствии с RFC. Естественно, в качестве адреса следует указывать только адреса Ваших MX серверов. Данное требование преследует единственную цель: если с Вашего ip адреса льётся спам от чужого имени (скажем – open relay работает), или другое абузивное поведение наблюдается, пострадавший может и не определить Ваш домен, чтобы отправить Вам приятное во всех отношениях послание. А ip адрес он уж точно определит :-). Мало того, RFC2821 (в том числе в разделе 4.1.1.3), RFC5321 предписываем нам принять почту просто на адрес “postmaster”, даже без указания домена. Но такого удовольствия я от Exchange Server добиться не смог.
P.S. Может возникнуть вопрос – а зачем столько группы рассылки наплодил, если всё равно один и тот же персонал обслуживает? Отвечу:
- одной группе два алиаса (mailnicName) не присвоите, поэтому через применение recipient Policy только для одного mailnicName адреса сможете добавить. Посему сколько Вам нужно mailnicName (“предписанных” RFC2142 адресов), столько и групп придётся создавать, если не хотим писать скрипты на poweshell;
- кроме получения почты на адреса postmaster@, hostmaster@ иногда возникает необходимость и оправить почту с этих адресов. Об этом применительно к Exchange Server и Outlook достаточно много статей в Интернете написано, но в любом случае – Вы сможете отправить почту с адреса группы или от имени группы, при этом используя только её основной адрес. Поэтому: сколько хотим иметь “предписанных” адресов для отправки, столько и групп создаём.
Один раз создали иерархию групп для всех специальных адресов, один раз создали recipient Policy и добавили свои домены – и требования RFC2142 выполнены. Почему даже провайдеры далеко не все выполняют требования RFC2142???
RSS комментарии
Обратная ссылка