Названия почтовых ящиков список: Топ 7 лучших почтовых сервисов для работы и постоянного использования

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

Если узел не настроен для приема почты напрямую, но реализует службу, для которой эта спецификация определяет имя почтового ящика, на этом узле должна быть установлена ​​запись MX RR (см. [RFC974]), и почтовые обменники, указанные в этом наборе RR, должны распознавать доменное имя узла, на который делается ссылка, как «локальное» для того, чтобы принимать почту, привязанную к определенному имени почтового ящика. Обратите внимание, что это верно, даже если рекламируемое доменное имя не совпадает с доменным именем хоста; например, если имя хоста сервера NNTP — DATA.RAMONA.VIX.COM, но он рекламирует доменное имя VIX.COM в своих заголовках «Путь:», то почта должна доставляться как на , так и на < [email protected]>, хотя эти адреса могут быть доставлены в разные конечные пункты назначения.

Областью действия хорошо известного имени почтового ящика является его доменное имя. Серверы, принимающие почту от имени домена, должны принимать и правильно обрабатывать имена почтовых ящиков для этого домена, даже если сам сервер не поддерживает соответствующую службу. Так, например, если NNTP-сервер объявляет домен верхнего уровня организации в заголовках «Путь:» (см. [RFC977]), почтовые обменники для этого домена верхнего уровня должны принимать почту на , даже если почтовый обменник сами по себе не обслуживают протокол NNTP.

2. Инварианты

Для общеизвестных имен, не связанных с конкретными протоколами, требуется только доменное имя верхнего уровня организации. Например, если доменное имя поставщика интернет-услуг — COMPANY.COM, то адрес должен быть действительным и поддерживаться, даже если клиенты, действия которых вызывают жалобы, используют хосты с более конкретными доменными именами, такими как SHELL1.COMPANY. .COM. Обратите внимание, однако, что допустимо и рекомендуется поддерживать имена почтовых ящиков для поддоменов, если это необходимо.

Имена почтовых ящиков должны распознаваться независимо от регистра символов. Например, POSTMASTER, postmaster, Postmaster, PostMaster и даже PoStMaStEr должны обрабатываться одинаково с доставкой в ​​один и тот же почтовый ящик.

Реализации этих широко известных имен должны учитывать ожидания отправителей, которые будут их использовать. Отправка обратно автоматического подтверждения почты обычно бывает полезной (хотя мы рекомендуем предостеречь от возможности «дуэли почтовых роботов» и возникающих в результате почтовых циклов).

3. Имена почтовых ящиков, связанных с бизнесом 

Эти имена связаны с родом деятельности организации. Имя INFO часто привязано к автоответчику с рядом доступных стандартных файлов.

4. Имена почтовых ящиков сетевых операций

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

5. Поддержка имен почтовых ящиков для определенных интернет-служб

Для основных служб интернет-протокола определен почтовый ящик для получения запросов и отчетов. (Здесь включены синонимы из-за их обширной установленной базы.) 

6. Почтовый ящик администрирования списков рассылки

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

Для списка рассылки, имя почтового ящика отправки которого:

ДОЛЖНО быть имя административного почтового ящика:

Программы управления списками рассылки, такие как MajorDomo и Listserv, также имеют одно имя почтового ящика, связанное с программным обеспечением на эта система — обычно название программного обеспечения — а не конкретный список в этой системе. Использование таких имен почтовых ящиков требует, чтобы участники знали, какое программное обеспечение списка используется на сайте. Это проблематично. Следовательно:

ОПРЕДЕЛЕННЫЕ ДЛЯ СПИСКА (-ЗАПРОС) ИМЕНА ПОЧТОВЫХ ЯЩИКОВ ТРЕБУЮТСЯ, НЕЗАВИСИМО ОТ НАЛИЧИЯ ОБЩЕГО СПИСКА ИМЕН ПОЧТОВЫХ ЯЩИКОВ.

7. Почтовый ящик администрирования службы доменных имен

В DNS (см. [RFC1033], [RFC1034] и [RFC1035]) запись Start Of Authority (SOA RR) имеет поле для указания имени почтового ящика зоны администратор. Это поле должно быть простым словом без метасимволов (например, «%» или «!» или «::»), а на соответствующих хостах почтового обменника должен использоваться псевдоним почты, чтобы направлять почту администрации зоны в соответствующий почтовый ящик.

Для простоты и регулярности настоятельно рекомендуется всегда использовать хорошо известное имя почтового ящика HOSTMASTER .

8. Почтовый ящик Автономной системы

В нескольких реестрах Интернета реализованы списки рассылки для контактов Автономной системы. Так, например, почта, отправленная на , на момент написания этой статьи будет достигать контактного лица по техническим вопросам для автономной системы 3557 в BGP4 (см. [RFC1654], [RFC1655] и [RFC1656]).

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

9. Вопросы безопасности

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

10. Ссылки

[RFC821] Постел, Дж., «Простой протокол передачи почты», STD 10, RFC 821, Институт информационных наук, август 1982 г.

[RFC822] Крокер, Д., «Стандарт формата интернет-текста ARPA». сообщения», STD 11, RFC 822, Университет Делавэра, август 1982 г.

[RFC959] Постел, Дж., и Дж. Рейнольдс, «Протокол передачи файлов (FTP)», STD 9, RFC 959, Институт информационных наук, Октябрь 1985 г.

[RFC974] Партридж, К., «Маршрутизация почты и доменная система», STD 14, RFC 9.74, CSNET CIC BBN Laboratories Inc, январь 1986 г.

[RFC976] Horton, M., «Стандарт формата обмена почтой UUCP», RFC 976, Bell Laboratories, февраль 1986 г.

[RFC977] Kantor, B., et al. , «Протокол передачи сетевых новостей: предлагаемый стандарт для потоковой передачи новостей», RFC 977, Калифорнийский университет, февраль 1986 г.

[RFC1033] Лоттор, М., «Руководство по работе с администраторами домена», RFC 1033, SRI International, ноябрь 1987 г.

[RFC1034] Мокапетрис, П., «Доменные имена — концепции и возможности», STD 13, RFC 1035, USC/Information Sciences Institute, 19 ноября.87.

[RFC1035] Мокапетрис, П., «Доменные имена — Реализация и спецификация» STD 13, RFC 1035, USC/Information Sciences Institute, ноябрь 1987 г.

[RFC1654] Рехтер, Ю., и др., «А Протокол пограничного шлюза 4 (BGP-4)», RFC 1654, T.J. Watson Research Center, IBM Corp., июль 1994 г.

[RFC1655] Рехтер Ю. и др., «Применение протокола пограничного шлюза в Интернете», RFC 1655, T.J. Watson Research Center, IBM Corp., июль 1994 г.

[RFC1656] Traina, P., «Дорожная карта документа по протоколу BGP-4 и опыт реализации», RFC 1656, cisco Systems, 19 июля.94.

[HTTP] Бернерс-Ли Т. и др., «Протокол передачи гипертекста — HTTP/1.0», RFC 1945, май 1996 г.

11. Благодарности

автор Пол Викси. Спасибо Стэну Барберу, Майклу Диллону, Джеймсу Олдриджу, Дж. Д. Фальку, Питеру Камински, Бретту Уотсону, Рассу Райту, Нилу МакБернетту и Эду Морину за их комментарии к черновику.

12. Адрес автора

Дэйв Крокер
Internet Mail Consortium
127 Segre Ave.
Santa Cruz, CA
Телефон: +1 408 246 8253
Электронная почта: [email protected]

RFC 2142 — Имена почтовых ящиков для общих служб, ролей и функций

Javascript отключен? Как и другие современные веб-сайты, IETF Datatracker использует Javascript. Пожалуйста, включите Javascript для полной функциональности.

 Сетевая рабочая группа Д. Крокер
Запрос комментариев: Консорциум 2142 Internet Mail
Категория: Трек стандартов 19 мая97
 ИМЕНА ПОЧТОВЫХ ЯЩИКОВ ДЛЯ
 ОБЩИЕ УСЛУГИ, РОЛИ И ФУНКЦИИ
Статус этого меморандума
 Этот документ определяет протокол отслеживания стандартов Интернета для
 Интернет-сообщество, а также запросы на обсуждение и предложения по
 улучшения. Пожалуйста, обратитесь к текущему выпуску «Интернет
 Стандарты официальных протоколов» (STD 1) для состояния стандартизации
 и статус этого протокола. Распространение этой памятки не ограничено.
АБСТРАКТНЫЙ
 Эта спецификация перечисляет и описывает почтовые адреса Интернета.
 (имя почтового ящика @ ссылка на хост) для использования при обращении к персоналу
 в организации. Имена почтовых ящиков предоставляются для обеих операций.
 и деловые функции. Дополнительные имена и псевдонимы почтовых ящиков не
 запрещено, но организации, поддерживающие обмен электронной почтой с
 Интернет рекомендуется поддерживать, ПО КРАЙНЕЙ МЕРЕ, каждое имя почтового ящика для
 связанная функция существует в организации.
1. ОБОСНОВАНИЕ И СФЕРА ПРИМЕНЕНИЯ
 В различных интернет-документах указаны имена почтовых ящиков, которые будут использоваться.
 при обращении к операторам новой услуги; например, [RFC822
 6.3, C.6] требует наличия имени почтового ящика  на всех хостах, у которых есть SMTP-сервер. Другие протоколы де-факто
 стандарты для общеизвестных имен почтовых ящиков, таких как  для
 NNTP (см. [RFC977]) и  для HTTP (см. [HTTP]).
 Стандарты де-факто также существуют для хорошо известных имен почтовых ящиков, которые
 ничего общего с конкретным протоколом, например,  и <ПРОБЛЕМА@домен>.
 Цель этой памятки состоит в том, чтобы агрегировать и указать базовый набор
 имена почтовых ящиков, которые организации должны поддерживать. Большинство
 организациям не нужно поддерживать полный набор имен почтовых ящиков
 определено здесь, поскольку не каждая организация реализует все
 сопутствующие услуги. Однако, если данная услуга предлагается,
 тогда должны поддерживаться связанные имена почтовых ящиков, что приводит к
 доставка получателю, соответствующему указанной услуге, или
 роль.
Отслеживание стандартов Крокера [Страница 1]
RFC 2142 Имена почтовых ящиков 19 мая97
 Если хост не настроен на прямой прием почты, но
 реализует службу, для которой эта спецификация определяет почтовый ящик
 имя, этот хост должен иметь набор MX RR (см. [RFC974]) и адрес электронной почты.
 обменники, указанные в этом наборе RR, должны распознавать указанный
 доменное имя хоста как «локальное» для приема почты
 для определенного имени почтового ящика. Обратите внимание, что это верно, даже если
 рекламируемое доменное имя не совпадает с доменным именем хоста; для
 Например, если имя хоста сервера NNTP — DATA.RAMONA.VIX.COM,
 рекламирует доменное имя VIX.COM в своих заголовках «Путь:», затем
 должен быть доставлен как в , так и в , хотя эти адреса могут быть
 доставлены в разные конечные пункты.
 Областью действия хорошо известного имени почтового ящика является его доменное имя. Серверы
 прием почты от имени домена должен принимать и корректно
 обрабатывать имена почтовых ящиков для этого домена, даже если сам сервер
 не поддерживает связанную службу. Так, например, если NNTP
 сервер объявляет домен верхнего уровня организации в «Пути:»
 заголовки (см. [RFC977]) почтовые обменники для этого домена верхнего уровня
 должен принимать почту на , даже если на почтовом обменнике
 сами по себе не обслуживают протокол NNTP. 2. ИНВАРИАНТЫ
 Для общеизвестных имен, не связанных с конкретными протоколами,
 доменное имя верхнего уровня организации должно быть действительным.
 Например, если доменное имя поставщика услуг Интернета
 COMPANY.COM, то адрес  должен быть действительным и
 поддерживается, даже несмотря на то, что клиенты, чья деятельность генерирует
 жалобы используют хосты с более конкретными доменными именами, такими как
 SHELL1.COMPANY.COM. Обратите внимание, однако, что это действительно и поощряется
 для поддержки имен почтовых ящиков для поддоменов, если это необходимо.
 Имена почтовых ящиков должны распознаваться независимо от регистра символов. Для
 например, POSTMASTER, postmaster, Postmaster, PostMaster и даже
 С PoStMaStEr нужно обращаться одинаково, с доставкой на тот же адрес.
 почтовый ящик.
 Реализации этих хорошо известных имен должны учитывать
 ожидания отправителей, которые будут их использовать. Отправка обратно
 обычно полезно автоматическое подтверждение почты (хотя мы рекомендуем
 предостережение от возможности «дуэли почтовых роботов» и
 получившиеся почтовые циклы). Отслеживание стандартов Крокера [Страница 2]
RFC 2142 Имена почтовых ящиков 19 мая97
3. НАЗВАНИЯ ПОЧТОВЫХ ЯЩИКОВ, СВЯЗАННЫХ С БИЗНЕСОМ
 Эти названия связаны с направлением деятельности организации.
 деятельность. Имя INFO часто связано с автоответчиком, с
 диапазон доступных стандартных файлов.
 ИСПОЛЬЗОВАНИЕ ОБЛАСТИ ПОЧТОВОГО ЯЩИКА
 -------------------------- ---------------- ----------------------- ----
 INFO Marketing Пакетная информация о
 организация, продукция и/или
 услуги по мере необходимости
 МАРКЕТИНГ Маркетинг Продуктовый маркетинг и
 Маркетинговые коммуникации
 ПРОДАЖИ Информация о покупке продукта
 ПОДДЕРЖКА Обслуживание клиентов Проблемы с продуктом или
 услуга
4. НАЗВАНИЯ ПОЧТОВЫХ ЯЩИКОВ ДЛЯ СЕТЕВЫХ ОПЕРАЦИЙ
 Операционные адреса предназначены для предоставления помощи клиентам,
 провайдеры и другие лица, испытывающие трудности с
 Интернет-сервис организации. ИСПОЛЬЗОВАНИЕ ОБЛАСТИ ПОЧТОВОГО ЯЩИКА
 -------------------------- ---------------- ----------------------- ----
 ЗЛОУПОТРЕБЛЕНИЕ Отношения с клиентами Ненадлежащее публичное поведение
 Сетевая инфраструктура NOC Network Operations
 БЕЗОПАСНОСТЬ Бюллетени или запросы по сетевой безопасности
5. ПОДДЕРЖКА НАЗВАНИЙ ПОЧТОВЫХ ЯЩИКОВ ДЛЯ КОНКРЕТНЫХ ИНТЕРНЕТ-СЛУЖБ
 Для основных служб интернет-протокола существует почтовый ящик, определенный для
 прием запросов и отчетов. (Здесь включены синонимы из-за
 их обширная установленная база.)
 ХАРАКТЕРИСТИКИ УСЛУГ ПОЧТОВОГО ЯЩИКА
 -------------------------- ---------------- ----------------------- ----
 ПОЧТОВЫЙ МАСТЕР SMTP [RFC821], [RFC822]
 HOSTMASTER DNS [RFC1033-RFC1035]
 USENET NNTP [RFC977]
 НОВОСТИ NNTP Синоним для USENET
 ВЕБ-МАСТЕР HTTP [RFC 2068]
 WWW HTTP Синоним для ВЕБ-МАСТЕР
 UUCP UUCP [RFC976]
 FTP FTP [RFC959]
Отслеживание стандартов Крокера [Страница 3]
RFC 2142 Имена почтовых ящиков, май 1997 г.
6. ПОЧТОВЫЙ ЯЩИК АДМИНИСТРИРОВАНИЯ СПИСКА РАССЫЛОК
 Списки рассылки имеют имя административного почтового ящика, к которому можно добавлять/удалять
 запросы и другие мета-запросы могут быть отправлены.
 Для списка рассылки, имя почтового ящика отправки которого: <СПИСОК@ДОМЕН> ДОЛЖНО быть имя административного почтового ящика: <СПИСОК-ЗАПРОС@ДОМЕН> Программное обеспечение для управления списками рассылки, такое как MajorDomo и
 Listserv, также имеют одно имя почтового ящика, связанное с
 программное обеспечение в этой системе — обычно название программного обеспечения — скорее
 чем определенный список в этой системе. Использование таких имен почтовых ящиков
 требует, чтобы участники знали тип программного обеспечения списка, используемого в
 сайт. Это проблематично. Следовательно:
 ТРЕБУЕТСЯ КОНКРЕТНЫЙ СПИСОК (-REQUEST) ИМЕН ПОЧТОВЫХ ЯЩИКОВ,
 НЕЗАВИСИМ ОТ НАЛИЧИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ОБЩЕГО СПИСКА
 НАЗВАНИЯ ПОЧТОВЫХ ЯЩИКОВ.
7. ПОЧТОВЫЙ ЯЩИК АДМИНИСТРИРОВАНИЯ СЛУЖБЫ ДОМЕННЫХ ИМЕН
 В DNS (см. [RFC1033], [RFC1034] и [RFC1035]) начало
 В авторитетной записи (SOA RR) есть поле для указания имени почтового ящика.
 администратора зоны.
 Это поле должно быть простым словом без метасимволов (например, "%"
 или "!" или "::"), и псевдоним почты должен использоваться для соответствующей почты.
 хосты-обменники для направления почты администрации зоны на соответствующие
 почтовый ящик.
 Для простоты и регулярности настоятельно рекомендуется
 хорошо известное имя почтового ящика HOSTMASTER всегда должно использоваться .
Отслеживание стандартов Крокера [Страница 4]
RFC 2142 Имена почтовых ящиков 19 мая97
8. ПОЧТОВЫЙ ЯЩИК АВТОНОМНОЙ СИСТЕМЫ
 Несколько интернет-реестров реализуют списки рассылки для автономных
 Системные контакты. Так, например, почта, отправленная на , будет
 на момент написания этой статьи связаться с техническим контактом для
 Автономная система 3557 в BGP4 (см. [RFC1654], [RFC1655] и
 [RFC1656]).
 Не все автономные системы зарегистрированы во всех реестрах,
 однако, поэтому недоставляемые имена почтовых ящиков по этой схеме должны
 рассматриваться как неудобство, а не как ошибка или стандарты
 нарушение. 9. ВОПРОСЫ БЕЗОПАСНОСТИ
 Атаки типа «отказ в обслуживании» (заполнение почтового ящика мусором) будут
 легче после того, как этот документ станет стандартом, так как больше систем
 будет поддерживать тот же набор имен почтовых ящиков.
10. ССЫЛКИ
 [RFC821] Постел, Дж., «Простой протокол передачи почты», STD 10, RFC
 821, Институт информационных наук, август 1982 г.
 [RFC822] Крокер, Д., «Стандарт формата интернет-текста ARPA».
 сообщения», STD 11, RFC 822, Делавэрский университет, август 1982 г.
 [RFC959] Постел, Дж., и Дж. Рейнольдс, "Протокол передачи файлов (FTP)",
 СТД 9, RFC 959, Институт информационных наук, октябрь 1985 г.
 [RFC974] Партридж, К., «Маршрутизация почты и доменная система», STD 14,
 RFC 974, CSNET CIC BBN Laboratories Inc, январь 1986 г.
 [RFC976] Хортон, М., "Стандарт формата обмена почтой UUCP", RFC
 976, Bell Laboratories, февраль 1986 г.
 [RFC977] Кантор, Б., и др., "Протокол передачи сетевых новостей: A
 Предлагаемый стандарт для потоковой передачи новостей», RFC
 977, Калифорнийский университет, февраль 1986 г. [RFC1033] Лоттор, М., «Руководство по работе с администраторами домена», RFC
 1033, SRI International, 19 ноября.87.
 [RFC1034] Мокапетрис, П., «Доменные имена — концепции и возможности»,
 STD 13, RFC 1035, USC/Институт информационных наук, ноябрь 1987 г.
Отслеживание стандартов Крокера [Страница 5]
RFC 2142 Имена почтовых ящиков, май 1997 г.
 [RFC1035] Мокапетрис, П., «Доменные имена — реализация и
 Спецификация" STD 13, RFC 1035, USC/Институт информационных наук,
 ноябрь 1987 года.
 [RFC1654] Рехтер, Ю., и др., "Протокол пограничного шлюза 4 (BGP-4)",
 RFC 1654, Т.Дж. Watson Research Center, IBM Corp., 19 июля.94.
 [RFC1655] Рехтер Ю. и др., «Применение пограничного шлюза
 Протокол в Интернете», RFC 1655, Исследовательский центр Т. Дж. Уотсона, IBM.
 Корп., июль 1994 г.
 [RFC1656] Traina, P., "Дорожная карта документа по протоколу BGP-4 и
 Опыт реализации», RFC 1656, cisco Systems, июль 1994 г.
 [HTTP] Бернерс-Ли, Т. и др., "Протокол передачи гипертекста --
 HTTP/1.