stringtranslate.com

Адрес электронной почты

Адрес электронной почты идентифицирует почтовый ящик, в который доставляются сообщения. В то время как ранние системы обмена сообщениями использовали различные форматы адресации, сегодня адреса электронной почты подчиняются набору конкретных правил, первоначально стандартизированных Инженерной группой Интернета (IETF) в 1980-х годах и обновленных RFC  5322 и 6854. Термин «адрес электронной почты» в эта статья относится только к спецификации addr в разделе 3.4 RFC 5322. RFC определяет адрес в более широком смысле как почтовый ящик или группу . Значением почтового ящика может быть либо имя-адрес , которое содержит отображаемое имя и адрес-спец , либо только более распространенная спецификация-адрес .

Адрес электронной почты, например [email protected] , состоит из локальной части, символа @ и домена , который может быть именем домена или IP-адресом, заключенным в скобки. Хотя стандарт требует, чтобы локальная часть была чувствительна к регистру, [1] он также призывает принимающие хосты доставлять сообщения независимо от регистра, [2] например, чтобы почтовая система в домене example.com обрабатывала Джона. Smith как эквивалент john.smith ; некоторые почтовые системы даже рассматривают их как эквивалент johnsmith . [3] Почтовые системы часто ограничивают выбор пользователями имени подмножеством технически разрешенных символов.

С введением интернационализированных доменных имен предпринимаются усилия по разрешению использования символов, отличных от ASCII, в адресах электронной почты.

Транспорт сообщений

Адрес электронной почты состоит из двух частей: локальной части (иногда имени пользователя, но не всегда) и домена; если домен представляет собой имя домена, а не IP-адрес, то SMTP-клиент использует имя домена для поиска IP-адреса почтового обмена. Общий формат адреса электронной почты — локальная часть @ домен , например jsmith@[192.168.1.2], [email protected] . Клиент SMTP передает сообщение на почтовый обмен, который может пересылать его на другой почтовый обмен, пока оно в конечном итоге не достигнет хоста почтовой системы получателя.

Передача электронной почты с компьютера автора и между почтовыми хостами в Интернете использует протокол SMTP , определенный в RFC  5321 и 5322, и расширения, такие как RFC 6531. Доступ к почтовым ящикам и управление ими могут осуществляться с помощью приложений на персональные компьютеры, мобильные устройства или сайты веб-почты с использованием протокола SMTP и протокола почтового отделения (POP) или протокола доступа к сообщениям в Интернете (IMAP).

При передаче сообщений электронной почты почтовые агенты пользователя (MUA) и агенты передачи почты (MTA) используют систему доменных имен (DNS) для поиска записи ресурса (RR) для домена получателя. Запись ресурса почтового обменника ( запись MX ) содержит имя почтового сервера получателя. При отсутствии записи MX запись адреса ( A или AAAA ) напрямую указывает почтовый хост.

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

Адреса, найденные в полях заголовка сообщения электронной почты, не используются напрямую почтовыми обменами для доставки сообщения. Сообщение электронной почты также содержит конверт сообщения, содержащий информацию для маршрутизации почты. Хотя адреса конверта и заголовка могут быть одинаковыми, поддельные адреса электронной почты (также называемые поддельными адресами электронной почты ) часто встречаются в спаме , фишинге и многих других интернет-мошенничествах. Это привело к появлению нескольких инициатив, цель которых — облегчить обнаружение подделок мошеннических электронных писем.

Синтаксис

Формат адреса электронной почты — local-part@domain , где длина локальной части может достигать 64 октетов , а длина домена — до 255 октетов. [4] Формальные определения находятся в RFC 5322 (разделы 3.2.3 и 3.4.1) и RFC 5321, а более удобочитаемая форма приведена в информационном RFC 3696 (написанном Дж. Кленсином, автором RFC 5321) и связанные ошибки.

Адрес электронной почты также может иметь связанное «отображаемое имя» (отображаемое имя) получателя, которое предшествует спецификации адреса и теперь заключено в угловые скобки, например: John Smith <[email protected]> . [5] Спамеры и фишеры по электронной почте часто используют «подмену отображаемого имени», чтобы обмануть своих жертв, используя ложное отображаемое имя или другой адрес электронной почты в качестве отображаемого имени. [6]

Более ранние формы адресов электронной почты для других сетей, кроме Интернета, включали другие обозначения, например, требуемые X.400 , и нотацию пути UUCP , в которой адрес задавался в виде последовательности компьютеров, через которые должно было пройти сообщение. быть передано. Он широко использовался в течение нескольких лет, но был заменен стандартами Интернета, обнародованными Инженерной группой Интернета (IETF).

Локальная часть

Локальная часть адреса электронной почты может быть не заключена в кавычки или заключена в кавычки.

Если он не заключен в кавычки, он может использовать любой из этих символов ASCII :

Если заключено в кавычки, оно может содержать пробел, горизонтальную табуляцию (HT), любое изображение ASCII, кроме обратной косой черты и кавычки, а также пару кавычек, состоящую из обратной косой черты, за которой следует HT, пробел или любое изображение ASCII; его также можно разделить между строками в любом месте, где появляется HT или пробел. В отличие от локальных частей без кавычек, адреса ".John.Doe"@example.comи разрешены."John.Doe."@example.com"John..Doe"@example.com

Максимальная общая длина локальной части адреса электронной почты составляет 64 октета. [8]

В дополнение к вышеуказанным символам ASCII, международные символы выше U+007F, закодированные как UTF-8 , разрешены RFC 6531, когда EHLO определяет SMTPUTF8 , хотя даже почтовые системы, поддерживающие SMTPUTF8 и 8BITMIME, могут ограничивать использование символов при назначении локальных символов. -части.

Локальная часть представляет собой либо строку с точкой, либо строку в кавычках; это не может быть сочетанием. Однако строки и символы в кавычках обычно не используются. [ нужна цитата ] RFC 5321 также предупреждает, что «узлу, который ожидает получать почту, СЛЕДУЕТ избегать определения почтовых ящиков, в которых локальная часть требует (или использует) форму строки в кавычках».

Локальная часть postmasterобрабатывается особым образом — она нечувствительна к регистру и должна быть перенаправлена ​​администратору электронной почты домена. Технически все остальные локальные части чувствительны к регистру, поэтому [email protected]и [email protected]указывают разные почтовые ящики; однако многие организации рассматривают прописные и строчные буквы как эквивалентные. Действительно, RFC 5321 предупреждает, что «хост, который ожидает получать почту, ДОЛЖЕН избегать определения почтовых ящиков, где... локальная часть чувствительна к регистру».

Несмотря на широкий спектр специальных символов, которые технически допустимы, организации, почтовые службы, почтовые серверы и почтовые клиенты на практике часто не принимают их все. Например, Windows Live Hotmail позволяет создавать адреса электронной почты только с использованием буквенно-цифровых символов, точки ( .), подчеркивания ( _) и дефиса ( -). [9] Общий совет — избегать использования некоторых специальных символов, чтобы избежать риска отклонения электронных писем. [10]

Согласно RFC 5321 2.3.11 «Почтовый ящик и адрес», «локальная часть ДОЛЖНА интерпретироваться и назначаться семантикой только хостом, указанным в домене адреса». Это значит, что нельзя делать никаких предположений о значении локальной части другого почтового сервера. Это полностью зависит от конфигурации почтового сервера.

Интерпретация локальной части зависит от соглашений и политик, реализованных на почтовом сервере. Например, чувствительность к регистру может различать почтовые ящики, отличающиеся только заглавными буквами локальной части, хотя это не очень распространено. [11] Gmail игнорирует все точки в локальной части адреса @gmail.com в целях определения личности учетной записи. [12]

Подадресация

Некоторые почтовые службы поддерживают тег, включенный в локальную часть, например, адрес является псевдонимом префикса локальной части. Обычно символы после плюса и реже символы после минуса, поэтому fred+bah@domain и fred+foo@domain могут оказаться в том же почтовом ящике, что и fred+@domain или даже fred@domain. Например, адрес [email protected] обозначает тот же адрес доставки, что и [email protected] . В RFC  5233 [13] это соглашение называется субадресацией , но оно также известно как плюс-адресация , адресация с тегами или почтовые расширения . Это может быть полезно для пометки электронных писем для сортировки и контроля спама. [14]

Адреса этой формы, в которых используются различные разделители между базовым именем и тегом, поддерживаются несколькими почтовыми сервисами, включая Andrew Project (plus), [15] Runbox (plus), [16] Gmail (plus), [14] Rackspace . (плюс), Yahoo! Mail Plus (дефис), [17] Apple iCloud (плюс), Outlook.com (плюс), [18] Proton Mail (плюс), [19] Fastmail (плюс и адресация поддоменов), [20] postale.io (плюс) ), [21] Pobox (плюс), [22] MeMail (плюс), [23] MMDF (равно), Qmail и Courier Mail Server (дефис). [24] [25] Postfix и Exim позволяют настраивать произвольный разделитель из допустимого набора символов. [26] [27]

Текст тега может использоваться для применения фильтрации [24] или для создания одноразовых или одноразовых адресов электронной почты . [28]

Домен

Часть доменного имени адреса электронной почты должна соответствовать строгим правилам: она должна соответствовать требованиям к имени хоста , списку DNS - меток, разделенных точками, причем каждая метка ограничена длиной 63 символа и состоит из: [7] : §2 

Это правило известно как правило LDH (буквы, цифры, дефис). Кроме того, домен может представлять собой литерал IP-адреса , заключенный в квадратные скобки [], например jsmith@[192.168.2.1]или jsmith@[IPv6:2001:db8::1], хотя это встречается редко, за исключением спама по электронной почте . Интернационализированные доменные имена (которые закодированы в соответствии с требованиями к имени хоста ) позволяют представлять домены, отличные от ASCII. В почтовых системах, соответствующих RFC 6531 и RFC 6532, адрес электронной почты может быть закодирован как UTF-8 , как локальная часть, так и доменное имя.

Комментарии разрешены как в домене, так и в локальной части; например, john.smith@(comment)example.comи [email protected](comment)эквивалентны [email protected].

RFC  2606 определяет, что некоторые домены, например те, которые предназначены для документации и тестирования, не должны быть разрешимыми и что в результате почта, адресованная почтовым ящикам в них и их поддоменах, должна быть недоставленной. Для электронной почты следует отметить example , valid , example.com , example.net и example.org .

Примеры

Действительные адреса электронной почты

Действительные адреса электронной почты с SMTPUTF8

Неверные адреса электронной почты

Валидация и проверка

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

Обычно считается, что адрес электронной почты состоит из двух частей, соединенных знаком @ ( @ ) , хотя технические спецификации, подробно описанные в RFC 822 и последующих RFC, более обширны. [30]

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

Для проверки адреса электронной почты пользователя можно использовать несколько методов проверки. Например, [31]

Некоторые компании предлагают услуги по проверке адреса электронной почты, часто с использованием интерфейса прикладного программирования , но нет никакой гарантии, что это даст точные результаты.

Интернационализация

IETF создает рабочую группу по техническим вопросам и стандартам, занимающуюся вопросами интернационализации адресов электронной почты, под названием « Интернационализация адресов электронной почты » (EAI, также известная как IMA, « Интернационализированный почтовый адрес»). [34] Эта группа подготовила RFC  6530, 6531, 6532 и 6533 и продолжает работать над дополнительными RFC, связанными с EAI.

Рабочая группа EAI IETF опубликовала RFC 6530 «Обзор и структура интернационализированной электронной почты», который позволяет использовать символы, отличные от ASCII, как в локальных частях, так и в домене адреса электронной почты. RFC 6530 предусматривает использование электронной почты в кодировке UTF-8 , что позволяет использовать полный набор Unicode . RFC 6531 предоставляет SMTP-серверам механизм согласования передачи содержимого SMTPUTF8 .

Основные концепции EAI включают обмен почтой в UTF-8. Хотя первоначальное предложение включало механизм перехода на более раннюю версию устаревших систем, сейчас от него отказались. [35] Локальные серверы отвечают за локальную часть адреса, тогда как домен будет ограничен правилами интернационализированных доменных имен , хотя они по-прежнему передаются в UTF-8. Почтовый сервер также отвечает за любой механизм сопоставления между формой IMA и любым псевдонимом ASCII.

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

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

Например, в дополнение к домену верхнего уровня .in правительство Индии в 2011 году [36] получило разрешение на использование «.bharat» (от Bhārat Gaṇarājya ), написанного семью различными алфавитами [37] [38] от носителей гуджрати, маратхи, бангали, тамильского, телугу, пенджаби и урду. Индийская компания XgenPlus.com утверждает, что является первым в мире поставщиком почтовых ящиков EAI, [39] а правительство Раджастана теперь предоставляет бесплатную учетную запись электронной почты на домене राजस्थान.भारत для каждого гражданина штата. [40] Ведущая медиакомпания Rajasthan Patrika запустила свой IDN-домен पत्रिका.भारत с доступной электронной почтой.

Приведенные ниже примеры адресов не будут обрабатываться серверами на основе RFC 5322, но разрешены RFC 6530. Серверы, соответствующие этому стандарту, смогут обрабатывать их:

Смотрите также

Рекомендации

  1. ^ Дж. Кленсин (октябрь 2008 г.). «Общие принципы синтаксиса и модель транзакций». Простой протокол передачи почты. п. 15. сек. 2.4. дои : 10.17487/RFC5321 . RFC 5321. Локальная часть почтового ящика ДОЛЖНА рассматриваться с учетом регистра.
  2. ^ Дж. Кленсин (октябрь 2008 г.). «Общие принципы синтаксиса и модель транзакций». Простой протокол передачи почты. п. 15. сек. 2.4. дои : 10.17487/RFC5321 . RFC 5321. Однако использование чувствительности к регистру локальных частей почтового ящика препятствует взаимодействию и не рекомендуется.
  3. ^ «...вы можете добавлять или удалять точки из почтового адреса, не меняя фактический адрес назначения; и все они попадут в ваш почтовый ящик...», Google.com
  4. ^ Кленсин, Дж. (октябрь 2008 г.). «Ограничения и минимумы размеров». Простой протокол передачи почты. IETF . сек. 4.5.3.1. дои : 10.17487/RFC5321 . РФК 5321.
  5. ^ «Спецификация адреса». Формат Интернет-сообщений. сек. 3.4. дои : 10.17487/RFC5322 . РФК 5322 . Проверено 14 марта 2023 г.
  6. ^ «Обнаружение подделки» . cyber.nj.gov . 19 ноября 2020 г. Проверено 17 апреля 2023 г.
  7. ^ Аб Кленсин, Дж. (февраль 2004 г.). RFC 3696. IETF . дои : 10.17487/RFC3696 . Проверено 1 августа 2017 г.: §3 
  8. ^ Кленсин, Дж. (октябрь 2008 г.). RFC 5321. IETF . сек. 4.5.3.1.1. дои : 10.17487/RFC5321 . Проверено 1 августа 2019 г.
  9. ^ «Зарегистрируйтесь в Windows Live» . Проверено 26 июля 2008 г.. Однако фраза скрыта, поэтому для ее прочтения необходимо либо проверить наличие неверного идентификатора, например, me#1 , либо прибегнуть к альтернативному отображению, например, без стиля или исходному виду.
  10. ^ «Символы в локальной части адреса электронной почты» . Проверено 30 марта 2016 г.
  11. ^ Чувствительны ли адреса электронной почты к регистру? Хайнц Чабишер
  12. ^ «Получение чужой почты». гугл.com .
  13. ^ Мерчисон, К. (2008). Сетчатая фильтрация электронной почты: расширение подадреса. IETF . дои : 10.17487/RFC5233 . РФК 5233 . Проверено 9 февраля 2019 г.
  14. ^ ab «Отправлять электронные письма с другого адреса или псевдонима». Справка Gmail . Проверено 13 декабря 2023 г.
  15. ^ «Обзор системы сообщений Эндрю» (PDF) . Проверено 17 апреля 2023 г.
  16. ^ «Субадресация/плюс адресация» . Проверено 1 января 2024 г.
  17. ^ «Одноразовые адреса в Yahoo Mail» . Помощь Yahoo .
  18. ^ Ривера, Рафаэль (17 сентября 2013 г.). «Outlook.com также поддерживает более простые псевдонимы электронной почты со знаком «+». Внутри Windows . Архивировано из оригинала 20 февраля 2014 г. Проверено 4 декабря 2023 г.
  19. ^ «Адреса и псевдонимы». протон.me .
  20. ^ «Плюс адресация и адресация поддоменов» . www.fastmail.com . Архивировано из оригинала 06 октября 2020 г. Проверено 6 октября 2020 г.
  21. ^ «Часто задаваемые вопросы postale.io по субадресации» . postale.io . Архивировано из оригинала 06 октября 2020 г. Проверено 6 октября 2020 г.
  22. ^ «Могу ли я использовать [email protected] со своей учетной записью Pobox?». helppot.pobox.com . nd Архивировано из оригинала 03 октября 2020 г. Проверено 3 октября 2020 г. Pobox поддерживает использование «+anystring» (плюс расширения) с любым адресом.
  23. ^ "МеПочта". www.memail.com . Проверено 6 октября 2020 г.
  24. ^ ab «Dot-Qmail, контроль доставки почтовых сообщений». Архивировано из оригинала 26 января 2012 года . Проверено 27 января 2012 г.
  25. ^ Силл, Дэйв. «4.1.5. Адреса расширения». Жизнь с qmail . Проверено 27 января 2012 г.
  26. ^ «Параметры конфигурации Postfix» . postfix.org .
  27. ^ «Параметры конфигурации Exim, «local_part_suffix»». exim.org .
  28. ^ Джина Трапани (2005) «Мгновенные одноразовые адреса Gmail»
  29. ^ «Доменные имена без точек в новых gTLD запрещены» . www.icann.org . ИКАНН . Проверено 23 марта 2020 г.
  30. ^ «Как Domino форматирует интернет-адрес отправителя в исходящих сообщениях» . Центр знаний IBM . Проверено 23 июля 2019 г.
  31. ^ «Рекомендации по отправке M3AAWG, версия 3» (PDF) . Рабочая группа по борьбе с сообщениями, вредоносным ПО и мобильными злоупотреблениями . Февраль 2015 года . Проверено 23 июля 2019 г.
  32. ^ Методы проверки и валидации для обеспечения качества адресов электронной почты, Ян Хорних, 2011 г., Оксфордский университет.
  33. ^ «4.10 Формы — HTML5». w3.org .
  34. ^ "Страницы статуса Eai" . Интернационализация адресов электронной почты (Активная рабочая группа) . IETF. 17 марта 2006 г. – 18 марта 2013 г. Проверено 26 июля 2008 г.
  35. ^ «Интернационализация адресов электронной почты (eai)» . IETF . Проверено 30 ноября 2010 г.
  36. ^ «25 января 2011 г. — Утверждение делегирования семи доменов верхнего уровня, представляющих Индию на разных языках» . Features.icann.org .
  37. ^ «Интернационализированные доменные имена (IDN) | Registry.In» . реестр.в . Проверено 17 октября 2016 г.
  38. ^ «Теперь получите свой адрес электронной почты на хинди» . Экономические времена . Проверено 17 октября 2016 г.
  39. ^ «Универсальное признание в Индии». 15 февраля 2017 г.
  40. Ссылки Он-Уилл и он -Мин Кейс Сингх - Уинстон". वसुन्धरा राजे (на хинди). 18 августа 2017 г. Проверено 20 августа 2017 г.

дальнейшее чтение

Внешние ссылки