stringtranslate.com

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

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

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

Из-за повсеместного распространения электронной почты в современном мире адреса электронной почты часто используются в качестве обычных имен пользователей многими веб-сайтами и службами, которые предоставляют профиль или учетную запись пользователя. [4] Например, если пользователь хочет войти в свой игровой профиль Xbox Live , он будет использовать свою учетную запись Microsoft в виде адреса электронной почты в качестве идентификатора имени пользователя, даже если служба в этом случае не является электронной почтой.

Передача сообщений

Адрес электронной почты состоит из двух частей: локальной части (иногда имя пользователя, но не всегда) и домена; если домен является доменным именем, а не 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 октетов. [5] Формальные определения содержатся в RFC 5322 (разделы 3.2.3 и 3.4.1) и RFC 5321, а более удобочитаемая форма приведена в информационном RFC 3696 (написанном Дж. Кленсином, автором RFC 5321) и связанных с ним исправлениях.

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

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

Местная часть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Домен

Часть доменного имени адреса электронной почты должна соответствовать строгим правилам: она должна соответствовать требованиям к имени хоста , списку разделенных точками DNS - меток, каждая метка должна быть ограничена длиной 63 символа и состоять из: [8] : §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 , invalid , example.com , example.net и example.org .

Примеры

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

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

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

Проверка и верификация

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

Адрес электронной почты обычно считается состоящим из двух частей, соединенных знаком « @ » , хотя техническая спецификация, подробно изложенная в RFC 822 и последующих RFC, более обширна. [32]

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

  1. ^ J. Klensin (октябрь 2008 г.). "Общие принципы синтаксиса и модель транзакций". Simple Mail Transfer Protocol. стр. 15. раздел 2.4. doi : 10.17487/RFC5321 . RFC 5321. Локальная часть почтового ящика ДОЛЖНА БЫТЬ чувствительна к регистру.
  2. ^ J. Klensin (октябрь 2008 г.). "General Syntax Principles and Transaction Model". Simple Mail Transfer Protocol. стр. 15. раздел 2.4. doi : 10.17487/RFC5321 . RFC 5321. Однако использование чувствительности к регистру локальных частей почтового ящика затрудняет взаимодействие и не рекомендуется.
  3. ^ "...вы можете добавлять или удалять точки из адреса электронной почты, не меняя фактический адрес назначения; и все они будут отправлены в ваш почтовый ящик...", Google.com
  4. ^ Моррисон, Сара (06.09.2021). «Как простой адрес электронной почты все усложняет». Vox . Получено 15.07.2024 .
  5. ^ Кленсин, Дж. (октябрь 2008 г.). «Ограничения и минимумы размера». Simple Mail Transfer Protocol. IETF . Раздел 4.5.3.1. DOI : 10.17487/RFC5321 . RFC 5321.
  6. ^ "Спецификация адреса". Формат интернет-сообщений. раздел 3.4. doi : 10.17487/RFC5322 . RFC 5322. Получено 14 марта 2023 г.
  7. ^ "Spotting a Spoofing". cyber.nj.gov . 19 ноября 2020 г. Получено 17 апреля 2023 г.
  8. ^ Аб Кленсин, Дж. (февраль 2004 г.). RFC 3696. IETF . дои : 10.17487/RFC3696 . Проверено 1 августа 2017 г.: §3 
  9. ^ Кленсин, Дж. (октябрь 2008 г.). RFC 5321. IETF . раздел 4.5.3.1.1. doi : 10.17487/RFC5321 . Получено 01.08.2019 .
  10. ^ "Зарегистрироваться в Windows Live" . Получено 2008-07-26 .. Однако фраза скрыта, поэтому для ее прочтения необходимо либо проверить наличие недействительного идентификатора, например, me#1 , либо прибегнуть к альтернативному отображению, например, no-style или source view.
  11. ^ "Символы в локальной части адреса электронной почты" . Получено 2016-03-30 .
  12. ^ Чувствительны ли адреса электронной почты к регистру? Архивировано 2016-06-03 на Wayback Machine Хайнцем Чабичером
  13. ^ "Получение чужой почты". google.com .
  14. ^ Murchison, K. (2008). Фильтрация электронной почты Sieve: расширение подадреса. IETF . doi : 10.17487/RFC5233 . RFC 5233 . Получено 9 февраля 2019 г. .
  15. ^ ab "Отправлять письма с другого адреса или псевдонима". Справка Gmail . Получено 13 декабря 2023 г.
  16. ^ "Обзор системы сообщений Эндрю" (PDF) . Получено 17 апреля 2023 г.
  17. ^ "Субадресация/Плюс-адресация" . Получено 1 января 2024 г.
  18. ^ "Одноразовые адреса в Yahoo Mail". Справка Yahoo .
  19. ^ Ривера, Рафаэль (17.09.2013). «Outlook.com также поддерживает более простые псевдонимы электронной почты «+». В Windows . Архивировано из оригинала 20.02.2014 . Получено 04.12.2023 .
  20. ^ «Плюс-адресация: лучший способ отслеживать спамеров в 2024 году». mailfence.com .
  21. ^ "Адреса и псевдонимы". proton.me .
  22. ^ "Адресация Plus и адресация поддоменов". www.fastmail.com . Архивировано из оригинала 2020-10-06 . Получено 2020-10-06 .
  23. ^ "Часто задаваемые вопросы postale.io о подадресации". postale.io . Архивировано из оригинала 2020-10-06 . Получено 2020-10-06 .
  24. ^ "Могу ли я использовать [email protected] с моей учетной записью Pobox?". helppot.pobox.com . nd Архивировано из оригинала 2020-10-03 . Получено 2020-10-03 . Pobox поддерживает использование "+anystring" (плюс расширения) с любым адресом.
  25. ^ "MeMail". www.memail.com . Получено 2020-10-06 .
  26. ^ ab "Dot-Qmail, Управление доставкой почтовых сообщений". Архивировано из оригинала 26 января 2012 г. Получено 27 января 2012 г.
  27. ^ Силл, Дэйв. "4.1.5. адреса расширения". Жизнь с qmail . Получено 27 января 2012 г.
  28. ^ "Параметры конфигурации Postfix". postfix.org .
  29. ^ "Параметры конфигурации Exim, "local_part_suffix"". exim.org .
  30. ^ Джина Трапани (2005) «Мгновенные одноразовые адреса Gmail»
  31. ^ "Новые доменные имена gTLD без точек запрещены". www.icann.org . ICANN . Получено 23 марта 2020 г. .
  32. ^ "Как Domino форматирует интернет-адрес отправителя в исходящих сообщениях". IBM Knowledge Center . Получено 23 июля 2019 г.
  33. ^ "M3AAWG Sender Best Common Practices, Version 3" (PDF) . Messaging, Malware and Mobile Anti-Abuse Working Group . Февраль 2015 . Получено 23 июля 2019 .
  34. ^ Методы проверки и подтверждения для обеспечения качества адресов электронной почты, Ян Хорних, 2011, Оксфордский университет
  35. ^ "4.10 Формы — HTML5". w3.org .
  36. ^ "Eai Status Pages". Интернационализация адресов электронной почты (активная рабочая группа) . IETF. 17 марта 2006 г. – 18 марта 2013 г. Получено 26 июля 2008 г.
  37. ^ "Интернационализация адресов электронной почты (eai)". IETF . Получено 30 ноября 2010 г.
  38. ^ "2011-01-25 - Утверждение делегирования семи доменов верхнего уровня, представляющих Индию на разных языках". features.icann.org .
  39. ^ "Интернационализированные доменные имена (IDN) | Registry.In". registry.in . Получено 2016-10-17 .
  40. ^ "Теперь получите свой адрес электронной почты на хинди". The Economic Times . Получено 17 октября 2016 г.
  41. ^ «Всеобщее принятие в Индии». 15 февраля 2017 г.
  42. ^ Он-Уилл и он-Мин Келли Сингх - Уинстон". वसुन्धरा राजे (на хинди). 18 августа 2017 г. Проверено 20 августа 2017 г.

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

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