RTFM.WIKI

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Кое-что о соглашениях об именах почтовых ящиков  ======

Источник: http://habrahabr.ru/blogs/sysadm/126822/

{{:network:black_mailbox.jpg? |}} Заведя для себя [[https://pdd.yandex.ru/|«почту для домена» на Яндексе]], я решил открыть свободную регистрацию посторонним юзерам почтовых ящиков на своем «модном» домене. Помимо включения функции [[https://secure.wikimedia.org/wikipedia/ru/wiki/Catch-all|catch-all]], которая направляет всю входящую почту несуществующих ящиков моего домена на мой основной ящик, предо мной встала необходимость зарезервировать за собой все «стандартные» названия ящиков, чтобы не было недоразумений, когда какое-то имя уже забил посторонний, и вся «служебная» почта уходит совсем не вам.\\

В П.Д.Д. можно, конечно, в любой момент экспроприировать любой ящик подконтрольного домена, но ведь осадочек-то остается. Я озадачился: **какие же имена почтовых ящиков являются стандартными и системными?** Техподдержка Яндекса ответила, что они резервируют для себя только имя postmaster@ на каждом домене, чтобы отслеживать жалобы и проблемы с почтой, и что на данный момент вопрос о наборе резервированных имен у них остается открытым. Далее, результат поиска в интернете оказался немного предсказуем.\\
(на картинке: знаменитый black mailbox, место паломничества уфологов-любителей)

===== RFC =====

Первое и главное, что я стремился найти — это RFC, коим оказался [[https://www.ietf.org/rfc/rfc2142.txt|RFC 2142, MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS]] (имена почтовых ящиков для общих сервисов, ролей и функций), в последней редакции 1997 года. Приведу только интересующую нас информацию. Исходя из документа, следующие почтовые ящики должны существовать и иметь следующее назначение:

==== Деловые почтовые ящики: ====

info@ — Отдел маркетинга, тут можно узнать краткую информацию об организации, продукции, сервисах.\\
marketing@ — Отдел маркетинга и взаимодействия продаж.\\
sales@ — Отдел продаж, заказ продукции и информация о заказах\\
support@ Отдел клиентской поддержки, проблемы с продуктом или услугами.\\
abuse@ — Взаимоотношения с клиентами, ящик должен быть всегда рабочим и валидным, сюда направляются жалобы клиентов, в том числе сообщения об «//Inappropriate public behaviour//».

==== Работа с сетью: ====

noc@ — Сетевые операции, сетевые инфраструктуры.\\
security@ — Сетевая безопасность, уведомления, оповещения или запросы.

==== Техническая поддержка отдельных интернетных служб ====

postmaster@ — SMTP, [RFC821], [RFC822]\\
hostmaster@ — DNS, [RFC1033-RFC1035]\\
usenet@ — NNTP, [RFC977]\\
news@ — NNTP, Synonym for USENET\\
webmaster@ — HTTP, [RFC 2068]\\
www@ — HTTP Synonym for WEBMASTER\\
uucp@ — UUCP, [RFC976]\\
ftp@ — FTP [RFC959]

==== Maillist сервис ====

//(рассматривать не будем, просто перечислим основные, там целая плеяда служебным имен и куча RFC, например [[https://tools.ietf.org/html/rfc2369|RFC2369]])//

list@\\
list-request@

//Сдается мне, что этот RFC 2142 одобрялся во времена расцвета доткомов, а значит потребность в подобных соглашениях была очень актуальна. Предполагалось, видимо, что сотрудники на автомате должны уметь отправлять почту на соответствующие всем известные адреса и ожидать соответствующих компетентных ответов.
//

Таким образом, следует сделать алиасы этих имен на свой «основной» email, чтобы никто не смог, например, на вашем домене открыть usenet конференцию, не стал из «отдела продаж» банчить валенками и не подписывался системным администратором всея сети с ящика noc@.

==== /etc/aliases ====

Стандартом де-факто для *nix систем является соглашение о почтовых именах, содержащееся в файле /etc/aliases. Который де-юре основывается на RFC и прочих документах, по каждому отдельному сервису.
Парадигма назначения почтовых ящиков для людей в *nix звучит примерно так: каждый юзернейм получает почтовый ящик на рабочей станции с таким же именем, как его логин. После создания юзернейма в системе вы уже можете отправлять и получать почту в свой аккаунт.(тут будет своё «но»: если разрешит root и верно [[https://secure.wikimedia.org/wikipedia/ru/wiki/Запись_MX|прописаны MX]]). Если хотите получить модный алиас — обратитесь к администратору, он его пропишет в /etc/aliases или еще где в почтовой системе.
То же самое касается и системных служб. Существует масса резервных имен типа @nobody, clamav@, www-data@, которые соответствуют системным учёткам служб, в реальной жизни не используются никем, кроме этих соответствующих служб и являются почтовыми алиасами системного пользователя root, поэтому мы их в расчет не возьмем, потому что все значимые имена ящиков сетевых служб мы уже узнали из предыдущего пункта. Добавим только root@

==== Современный интернет и прочие негласные соглашения об именах ящиков. ====

Попробуем вместе с вами найти самые частые имена, которые хозяева доменов оставляют для себя и используют в качестве административных, деловых и личных контактах.\\
admin@\\
administrator@ (мьсе, знающие в этом толк, могут добавить локализованные имена админа в Windows, вроде administrador, administrateur)\\
user@\\
mail@\\
blog@\\
office@\\
job@ (и иногда resume@ и hr@)-для отправки и приема заявлений на работу и резюме.\\
spam@ — иногда его ставят как алиас к abuse@ или postmaster@, для жалоб на спам, очевидно.\\
billing@ — для биллинга. К.О.\\
account@ — для бухгалтерии и поддержки аккаунтов.\\
domain@domain.tld — имя ящика повторяет домен, очевидно, для эстетики.\\
alex@, boss@ — не стесняйтесь забить свои имена, фамилии и ники, чтобы исключить фактор социального инжиниринга, когда, вас, например, зовут Алексей, и ваша жена, прекрасно зная что вы купили vashdomen.ru, получает с ящика alex@vashdomen.ru письмо сомнительного содержания — не ровен час поверит злоумышленнику.\\
Вы можете что-то добавить в этот лист.

Кроме этого мне почти ничего не известно о соглашениях почтовых имен в системах Windows, существуют ли они в действительности?

Таким образом, зарезервировав все эти имена, как алиасы для своего основного ящика на домене, вы обезопасите себя, в том, числе от мейлбокс-сквоттерства и злонамеренного использования ящиков с «системными» именами. Так же вся «служебная» переписка по вашему домену, которая может придти на системные имена не останется без внимания. Если вы организовываете почту для офиса, то подобные соглашения могут быть так же полезны вам.