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

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

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

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

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

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

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

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

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

• прописные и строчные латинские буквы A к Z и a к z
• цифры 0 к 9
• печатные символы !#$%&'*+-/=?^_`{|}~
• точка ., при условии, что это не первый и не последний символ, а также при условии, что он не появляется последовательно (например, [email protected] не допускается).

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

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

• Пробел и специальные символы "(),:;<>@[\] разрешены с ограничениями (они разрешены только внутри строки в кавычках, как описано в параграфе ниже, и в этой строке в кавычках любой обратной косой черте или двойной кавычке должна предшествовать один раз обратная косая черта);
• Комментарии разрешены с круглыми скобками на обоих концах локальной части; например, john.smith(comment)@example.com и (comment)[email protected] оба эквивалентны [email protected].

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

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

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

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

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

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

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

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

Адреса этой формы, в которых используются различные разделители между базовым именем и тегом, поддерживаются несколькими почтовыми сервисами, включая Andrew Project (plus), Ранбокс (плюс), Gmail (плюс), Rackspace (плюс), Yahoo! Почта Плюс (дефис), от Apple iCloud (плюс), Outlook.com (плюс), Протонная почта (подробнее), Fastmail (плюс и адресация поддоменов), postale.io (плюс), почтовый ящик (плюс), MeMail (подробнее), и MTA, такие как MMDF (равно), Qmail и Courier Mail Server (дефис). Postfix и Exim позволяют настроить произвольный разделитель из допустимого набора символов.

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

Домен

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

• Прописные и строчные латинские буквы A к Z и a к z;
• Цифры 0 к 9, при условии, что доменные имена верхнего уровня не являются полностью цифровыми;
• Дефис -, при условии, что это не первый и не последний символ.

Это правило известно как правило 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 .

Примеры

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

• [email protected]
• [email protected]
• [email protected] (регистр всегда игнорируется после @ и обычно до него)
• [email protected] (однобуквенная локальная часть)
• [email protected]
• [email protected] (может быть направлен на [email protected] входящие в зависимости от почтового сервера)
• name/[email protected] (косая черта является печатным символом и разрешена)
• admin@example (местное доменное имя без TLD , хотя ICANN настоятельно не рекомендует использовать адреса электронной почты без точек). )
• [email protected] (см. Список доменов верхнего уровня Интернета )
• " "@example.org (пробел между кавычками)
• "john..doe"@example.org (в кавычках двойная точка)
• [email protected] (bangified хост-маршрут, используемый для почтовых программ uucp)
• "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com (включите небуквенный символ И несколько символов в знаке , первый из которых заключен в двойные кавычки)
• user%[email protected] (% избежал почтового маршрута к [email protected] через example.org)
• [email protected] (локальная часть заканчивается небуквенно-цифровым символом из списка разрешенных печатных символов)
• postmaster@[123.123.123.123] (IP-адреса разрешены вместо доменов в квадратных скобках, но настоятельно не рекомендуются)
• postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334] (IPv6 использует другой синтаксис)
• _test@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334] (начните с подчеркивания другого синтаксиса)

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

• I❤️[email protected] ( эмодзи разрешены только с SMTPUTF8)

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

• abc.example.com (без символа @)
• a@b@[email protected] (допускается только один символ @ вне кавычек)
• a"b(c)d,e:f;g<h>i[j\k][email protected] (ни один из специальных символов в этой локальной части не может быть вне кавычек)
• just"not"[email protected] (строки в кавычках должны быть разделены точкой или быть единственным элементом, составляющим локальную часть)
• this is"not\[email protected] (пробелы, кавычки и обратные косые черты могут существовать только в строках, заключенных в кавычки, и им предшествует обратная косая черта)
• this\ still\"not\\[email protected] (даже если они экранированы (перед ними стоит обратная косая черта), пробелы, кавычки и обратная косая черта все равно должны содержаться в кавычках)
• 1234567890123456789012345678901234567890123456789012345678901234+x@example.com (локальная часть длиннее 64 символов)
• i.like.underscores@but_they_are_not_allowed_in_this_part (подчеркивание не допускается в доменной части)

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

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

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

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

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

• Ссылки для проверки. Проверка адреса электронной почты часто выполняется для создания учетной записи на веб-сайтах путем отправки электронного письма на указанный пользователем адрес электронной почты со специальной временной гиперссылкой. При получении пользователь открывает ссылку, сразу активируя аккаунт. Адреса электронной почты также полезны как средство доставки сообщений с веб-сайта, например, сообщений пользователя, действий пользователя, в почтовый ящик электронной почты.
• Формальные и неформальные стандарты: RFC 3696 содержит конкретные рекомендации по проверке интернет-идентификаторов, включая адреса электронной почты. Вместо этого некоторые веб-сайты пытаются оценить достоверность адресов электронной почты с помощью произвольных стандартов, например, отклоняя адреса, содержащие допустимые символы, такие как + и / , или вводя произвольные ограничения на длину. Интернационализация адреса электронной почты обеспечивает гораздо больший диапазон символов, чем позволяют многие текущие алгоритмы проверки, например, все символы Юникода выше U+0080, закодированные как UTF-8 .
• Алгоритмические инструменты. Крупным веб-сайтам, рассылкам массовых рассылок и спамерам требуются эффективные инструменты для проверки адресов электронной почты. Такие инструменты зависят от эвристических алгоритмов и статистических моделей .
• Репутация отправителя. Репутация отправителя электронной почты может использоваться для проверки того, заслуживает ли отправитель доверия или является потенциальным спамером. Факторы, которые могут быть включены в оценку репутации отправителя, включают качество прошлых контактов или контента, предоставленного с помощью IP-адреса отправителя или адреса электронной почты, а также уровень взаимодействия с ним.
• Проверка на основе браузера: формы HTML5, реализованные во многих браузерах, позволяют браузеру обрабатывать проверку адреса электронной почты.

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

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

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

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

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

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

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

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

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

• Латинский алфавит с диакритическими знаками : élé [адрес электронной почты защищен]
• Греческий алфавит : δοκιμή@παράδειγμα.δοκιμή
• Традиционные китайские иероглифы : Я покупаю @home.Hong Kong
• Японские иероглифы : [email protected].
• Символы кириллицы : медведь@с-балалайкой.рф.
• Персонажи деванагари : संपर्क@डाटामेल.भारत

См. также

• Методы защиты от спама
• Почтовый клиент
• Электронный ящик
• Аутентификация по электронной почте
• Адрес электронной почты вне Интернета
• Международная электронная почта

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

• RFC   821 Простой протокол передачи почты (устарел из-за RFC 2821 и 5321)
• Стандарт RFC   822 для формата текстовых сообщений Интернета ARPA (устарел благодаря RFC 2822) (ошибки)
• Доменные имена RFC   1035 , реализация и спецификация (ошибки)
• Требования RFC   1123 к интернет-хостам, приложениям и поддержке (обновлено RFC 2821, RFC 5321) (ошибки)
• RFC   2142 Имена почтовых ящиков для общих служб, ролей и функций (ошибки)
• RFC   2821 Simple Mail Transfer Protocol (устарел RFC 821, обновлен RFC 1123, устаревший RFC 5321) (ошибки)
• Формат Интернет-сообщений RFC   2822 (устарел RFC 822, устаревший RFC 5322) (ошибки)
• RFC   3696. Прикладные методы проверки и преобразования имен (ошибки)
• RFC   4291 Архитектура IP-адресации версии 6 (обновлено RFC 5952) (ошибки)
• RFC   5321 Simple Mail Transfer Protocol (устаревший RFC 2821, обновления RFC 1123) (ошибки)
• Формат интернет-сообщений RFC   5322 (устаревший RFC 2822, обновленный RFC 6854) (ошибки)
• RFC   5598 Архитектура почты Интернета
• RFC   5952. Рекомендация по представлению текста адреса IPv6 (обновления RFC 4291) (ошибки)
• Обзор RFC   6530 и структура интернационализированной электронной почты (устаревшие RFC 4952, 5504, 5825)
• Расширение SMTP RFC   6531 для интернационализированной электронной почты (устарело RFC 5336)
• Обновление RFC   6854 в формате интернет-сообщений, позволяющее использовать групповой синтаксис в полях заголовка «От:» и «Отправитель:» (обновление RFC 5322)

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

• Подтвердить адрес электронной почты в Wikibooks
• Лучшие практики в Wikibooks
• СМИ, связанные с адресом электронной почты на Викискладе?