22 августа 2011 в 21:00

Кое-что о соглашениях об именах почтовых ящиков


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

RFC


Первое и главное, что я стремился найти — это RFC, коим оказался 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, например RFC2369)
list@
list-request@

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

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

/etc/aliases


Стандартом де-факто для *nix систем является соглашение о почтовых именах, содержащееся в файле /etc/aliases. Который де-юре основывается на RFC и прочих документах, по каждому отдельному сервису.
Парадигма назначения почтовых ящиков для людей в *nix звучит примерно так: каждый юзернейм получает почтовый ящик на рабочей станции с таким же именем, как его логин. После создания юзернейма в системе вы уже можете отправлять и получать почту в свой аккаунт.(тут будет своё «но»: если разрешит root и верно прописаны 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, существуют ли они в действительности?

Таким образом, зарезервировав все эти имена, как алиасы для своего основного ящика на домене, вы обезопасите себя, в том, числе от мейлбокс-сквоттерства и злонамеренного использования ящиков с «системными» именами. Так же вся «служебная» переписка по вашему домену, которая может придти на системные имена не останется без внимания. Если вы организовываете почту для офиса, то подобные соглашения могут быть так же полезны вам.
Укропина @ykrop
карма
17,2
рейтинг 0,0
Похожие публикации

Комментарии (35)

  • +13
    Ага, а MAILER-DAEMON забыли. Кстати, не стоит это редиректить на себя, ибо по стандартным адресам рассылают стандартный спам.
    • 0
      Яндекс вполне достойно фильтрует такой спам. Говорю это как владелец ящика, на который заведено пол сотни пересылок и алисов.
  • +1
    мне кажется, что MAILER-DAEMON@ — это служебка, в действительности не существующий ящик, с которого сыпятся только отлупы. делать такой мейлбокс — чревато непредсказуемостью, я бы поостерегся, например.
    • 0
      Если не сделать, отлупы от вашей почтовой системы могут не дойти до криво настроенных серверов с sender validation, который пытается пробить существование вашего MAILER-DAEMON.
      • +1
        Отлуп идет с адреса null <> поэтому никакого sender validation там не может быть. Mailer-daemon лишь в заголовках присуствует.
        • 0
          Кстати и правда. У меня путаница в голове была. Сбило с толку, что postfix требует прописывать алиас для MAILER-DAEMON и ругается, если его нет.
  • +4
    А как же noreply@?
    • +2
      хороший вопрос, это ведь тоже «несуществующий» ящик. но что произойдет, если кто-то начнет писать «административные» сообщения с такого адреса?
      • +4
        Ему не ответят :(
        • +1
          Вы плохо знаете пользователей — ответят еще как. Редко кто вчитывается что адрес noreply@ называется — все равно отвечают.
  • +6
    Насчет фото: этот ящик не принадлежит базе Эдвард (area 51). Это ящик одного рачно, владельцем котрого и является Стив Медлин, имя которого указано на ящике. Просто этот ящик пользуется популярностью среди безмозглых искателей НЛО.
  • 0
    noc@ — Сетевые операции, сетевые инфраструктуры.
    security@ — Сетевая безопасность, уведомления, оповещения или запросы.

    вообще-то это должно бы показывать на сисадмина управляющего сетью и безопасностью соотв., но никак не на вас — вы пользователь этой системы.

    все известные мне почтовые системы нарушают это соглашение и, по-хорошему, такие почтовые системы должны быть закрыты и к операторам применены санкции.
    • +1
      эти адреса имеют смысл, если «за доменом» скрывается целая сетка, или хотя бы ваш сервер. например, может случиться такая ситуация, когда вы закрыли контору(с пасьянсом и секретаршами!), на которую был назначен домен, и перевели почту со всего домена на себя.
      • +1
        последнего предложения не понял.
  • +1
    Ну и кроме noreply еще иногда с no-reply присылают письма
  • +5
  • 0
    Попробуйте подойти проще к вопросу.
    Зарезервируйте только адрес support@ваш-супер-домен.ru.
    Оставляйте везде только один этот ящик (далее настройте фильтры/правила как вам будет удобно).
    Пусть ваши любимые пользователи не держат в голове 10 адресов по которым можно с вами связаться.
    Не нужно пользователю думать на какой ящик ему лучше написать по его вопросу.
    У сайта должна быть одна точка входа.
    Вашу же персональную почту лучше держать на обычном домене @yandex.ru/@gmail.com.
    • +2
      ну я так и решил: catchall + aliases = 1 mailbox. просто передо мной стояла задача определить эти aliases, чтобы не дать зарезервировать другим на Yandex P.D.D.
    • 0
      Лично я, противник бесплатной почты. Малоли, завтра сервис ляжет и я останусь без почты?
      Не у меня есть мой ящик user@super-my-domen.com и моя почта всегда со мной. Я в праве выбрать любой почтовый сервер, где размещу свою почту.
      • +1
        ну важную почту всегда лучше синхронизировать по IMAP с каким-нить приватным местом. это понятно.

        а вот вероятность падения вашего сервера и всего гугла — примерно одинакова. причём у гугла больше шансов остаться работать.
        • 0
          извиняюсь, не совсем точно написал. Я имел виду совсем ляжет, все закрыли сервер и не работает компания.
          В любом случае все падения, будут отчасти мои проблемы и я буду выбирать поставщика услуг.
  • 0
    добавил бы в список
    i@
    iam@
    me@
  • +5
    О сколько нам открытий чудных готовит RFC…

    Ровно аналогичным же вопросом озаботился почти год назад, 23 сентября 2010, хабра-пользователь navion в хабра-статье «Почтовые ящики для стандартных сервисов, ролей и функций». Жизнь тем временем идет по спирали.
  • +1
    По состоянию на декабрь 2010 Яндекс запрещал 2 адреса: postmaster@ и abuse@. Но он не запрещал создать рассылку и подписаться на неё.
    • +1
      Гугл аналогично запрещает эти адреса. Мало того — он их просматривает. В справке же написано, что можно создать список рассылки с такими именами, для того чтобы тоже получать письма приходящие на эти адреса, как я, в принципе, и сделал :-)
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Не знаю как там у Яндекса, но все приличные почтовики уже давно авторизацию при отправке спрашивают. Яндекс думаю не исключение.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          А сервер не в состоянии взять и сверить связку логи/пароль с почтовыми адресами которые за этим пользователем закреплены?
          • +2
            исторически так повелось, что посторонний пользователь может вписать какие угодно поля в заголовок письма, в том числе и from и reply-to и отправить его кому угодно со своего почтового сервера, минуя «официальный». с этим сейчас борются на «другой» стороне, помечая такие письма как недоверенные и проверяя spf, например.
            • 0
              Ну тогда это мрачная дырка.
              • +2
                просто мы, пользуясь e-mail, живем по принципу Неуловимого Джо. я скажу больше — e-mail является не больше чем цифровым эквивалентом обычной почты, с таким же уровнем защищенности, и отсутствием всякой гарантии доставки. данные передаются почти открытым текстом и совершенно не защищены от модификации или подслушивания. через e-mail нельзя вести сколько-нибудь серьезную переписку, впрочем, как и через обычную почту. правда, сейчас никто кроме провайдеров или сисадминов почтовых серверов прочитать вашу почту не могут, к тому же почтовики переходят на защищеные протоколы, что у меньшает, но не убирает вероятность вмешательства.
                • 0
                  Ну если уж совсем-совсем строго подходить, то всё же данные могут иметь защиту от модификации/подслушивания (на прикладном уровне — S/MIME и PGP, на транспортном — DKIM).
          • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Спасибо за статью, очень приятно читать грамотные статьи со ссылками на RFC.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.