Что такое алиасы электронной почты. Алиасы почтовых адресов

Заведя для себя «почту для домена» на Яндексе , я решил открыть свободную регистрацию посторонним юзерам почтовых ящиков на своем «модном» домене. Помимо включения функции 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, ,
hostmaster@ - DNS,
usenet@ - NNTP,
news@ - NNTP, Synonym for USENET
webmaster@ - HTTP,
www@ - HTTP Synonym for WEBMASTER
uucp@ - UUCP,
ftp@ - FTP
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@ - для бухгалтерии и поддержки аккаунтов.
[email protected] - имя ящика повторяет домен, очевидно, для эстетики.
alex@, boss@ - не стесняйтесь забить свои имена, фамилии и ники, чтобы исключить фактор социального инжиниринга, когда, вас, например, зовут Алексей, и ваша жена, прекрасно зная что вы купили vashdomen.ru, получает с ящика [email protected] письмо сомнительного содержания - не ровен час поверит злоумышленнику.
Вы можете что-то добавить в этот лист.

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

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

Для пересылки. Если, к примеру, у пользователя имеется адрес [email protected] , а ему необходим адрес [email protected] . В этом случае можно этот адрес сделать алиасом к основному, и вся поступающая почта будет собираться в одном почтовом ящике.

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

Использование

Алиас электронного адреса может быть создан на почтовом сервере . Каждый алиас email-адреса просто пересылает электронные сообщения на каждый из указанных адресов. Алиасы электронных адресов часто используются для создания псевдонимов для длинных или плохо запоминаемых email-адресов. Алиасы можно также использовать для создания общих почтовых адресов таких, как [email protected] или [email protected] . В UNIX-подобных системах алиасы почтовых адресов могут быть помещены в файл алиасов и иметь вид: local-alias-name: adifferentlocaluser, anotherlocaluser, [email protected]

Вопросы управления

Сообщение, которое пересылается через алиас почтового адреса, сохраняет исходные данные об отправителе и получателе. Если сообщение является скрытой копией, то получатель может сказать, было ли сообщение передано через алиас путем анализа заголовка сообщения. Однако, стандарт не требует упоминания в заголовке получателя сообщения. Таким образом, получатели сообщений могут быть не в состоянии восстановить, какой, в конечно итоге, адрес электронной почты был использован отправителем для доставки сообщения в почтовый ящик.

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

См. также

Пересылка (форвардинг)


Wikimedia Foundation . 2010 .

Заведя для себя «почту для домена» на Яндексе , я решил открыть свободную регистрацию посторонним юзерам почтовых ящиков на своем «модном» домене. Помимо включения функции 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, ,
hostmaster@ - DNS,
usenet@ - NNTP,
news@ - NNTP, Synonym for USENET
webmaster@ - HTTP,
www@ - HTTP Synonym for WEBMASTER
uucp@ - UUCP,
ftp@ - FTP
Maillist сервис
(рассматривать не будем, просто перечислим основные, там целая плеяда служебным имен и куча RFC, например RFC2369)
list@
list-request@

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

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

/etc/aliases

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

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

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

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

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

Для пересылки. Если, к примеру, у пользователя имеется адрес [email protected] , а ему необходим адрес [email protected] , то можно этот адрес сделать алиасом к основному, и вся поступающая почта будет собираться в одном почтовом ящике.

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

Энциклопедичный YouTube

    1 / 3

    Как создать красивый почтовый адрес

    Как настроить письмо для подтверждения подписки

    Drupal 7 Pathauto Module - Daily Dose of Drupal episode 71

    Субтитры

Использование

Алиас электронного адреса может быть создан на почтовом сервере . Каждый алиас email-адреса просто пересылает электронные сообщения на каждый из указанных адресов. Алиасы электронных адресов часто используются для создания псевдонимов для длинных или плохо запоминаемых email-адресов. Алиасы можно также использовать для создания общих почтовых адресов, таких как [email protected] или [email protected] . В UNIX-подобных системах алиасы почтовых адресов могут быть помещены в файл алиасов и иметь вид: local-alias-name: adifferentlocaluser, anotherlocaluser, [email protected]

Вопросы управления

Сообщение, которое пересылается через алиас почтового адреса, сохраняет исходные данные об отправителе и получателе. Если сообщение является скрытой копией, то получатель может сказать, было ли сообщение передано через алиас, путём анализа заголовка сообщения. Однако стандарт не требует упоминания в заголовке получателя сообщения. Таким образом, получатели сообщений могут быть не в состоянии восстановить, какой, в конечном итоге, адрес электронной почты был использован отправителем для доставки сообщения в почтовый ящик.

Получатели, которые не могут проследить, какие адреса отправителя использовались, не могут попросить отправителя прекратить отправку, так как отправитель, скорее всего, не сможет связать их текущий адрес электронной почты с одним из адресов, используемых для отправки. Даже если пользователи имеют возможность узнать точный адрес, используемый для отправки, их почтовый клиент не может обеспечить удобный способ передать ответ с использованием адреса отправителя. Другими словами, использование алиасов почтовых адресов не является обратимым. Это особенно актуально в ситуации, когда отправитель не даёт надёжного механизма для ответа в теле сообщения. Так, например, информационные сообщения могут быть отправлены списку получателей, что требует значительно меньше ресурсов, чем отправка письма каждому получателю отдельно.

Алиас считается одним из самых распространенных понятий в Интернете. Многие пользователи привыкли использовать это слово, и стоит отметить, что это достаточно удобный термин. Но некоторые люди до сих пор задаются вопросом: алиасы - что это? Его говорит сам за себя, и означает он - псевдоним. Алиасом принято называть двойники доменных имен сайтов или электронных почтовых ящиков. Одним из самых распространенных считается приставка www. Чтобы значение термина "алиас" было понятнее, приведем пример: первоначальное имя сайта звучит так сайт.ru, а его копия будет звучать www.сайт.ru.

Алиасы - что это для электронной почты

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

Алиасы для сайтов

Отвечая на вопрос о том, алиасы - что это для сайтов, можно сказать, что это также очень удобное средство. Очень часто при вводе названия сайта пользователь может совершить ошибку и опечататься. Если собрать все возможные варианты опечаток относительно вашего адреса, и добавить их в качестве альтернативных ссылок на сайт, то пользователь так или иначе попадет на нужную ему страничку. Также алиасы позволяют регистрировать сайт в нескольких К примеру, это сайт.ru, сайт.org и сайт.com. Стоит отметить, что алиасы схватывают все изменения на главном ресурсе автоматически. Иными словами, если добавить статью на главный домен сайта, то на всех его копиях изменения также отобразятся.

Кириллица для алиасов

Поскольку алиасы являются достаточно удобным средством, неудивительно, что их улучшают и модернизируют под современные нужды пользователей интернета. Одним из таких улучшений является добавление кириллической формы в их написание. Это очень удобно, поскольку пользователи часто забывают сменить раскладку перед вводом сайта с русского на английский или же помнят название только в русском варианте. Благодаря улучшениям алиасов, теперь они точно попадут по назначенному адресу.

Что такое алиасы

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