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, в адресах электронной почты.

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

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

Домен

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

Примеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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