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

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

Адрес электронной почты, такой как [защищенная электронная почта] , состоит из локальной части , символ @и домена , который может быть доменным именем или IP-адресом, заключенным в скобки. Хотя стандарт требует, чтобы местная часть была чувствительной к случаям, Он также призывает к тому, чтобы приемные хосты доставляли сообщения независимым от случая, доменном примере система в , что почтовая . Например Некоторые почтовые системы даже рассматривают их как эквивалентные Джонсмиту . Почтовые системы часто ограничивают выбор имени пользователей подмножеством технически разрешенных символов; С внедрением интернационализированных доменных имен усилия стремятся разрешить не ascii символы в адресах электронной почты.

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

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

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

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

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

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

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

Синтаксис

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

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

Более ранние формы адресов электронной почты для других сетей, чем в Интернете, включали другие обозначения, такие как то, что требуемые для X.400 , и UUCP нотация пута , в которой адрес был указан в виде последовательности компьютеров, через которые должно передаваться. Это широко использовалось в течение нескольких лет, но было заменено интернет -стандартами, обнародованными целевой группой Internet Engineering (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 позволяет только создавать адреса электронной почты, используя Alphanumerics, Dot ( .), подчеркивание ( _) и дефис ( -). Общий совет состоит в том, чтобы избежать использования некоторых специальных персонажей, чтобы избежать риска отклоненных электронных писем.

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

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

Суб-адресация

Некоторые почтовые службы поддерживают тег, включенный в локальную часть, так что адрес является псевдонимом префикса локальной части. Обычно символы, следующие плюсу и реже, символы, следуя минус, так что Fred+Bah@Domain и Fred+Foo@Domain могут оказаться в том же почтовом ящике, что и домен Fred+@или даже с доменом Fred@. Например, адрес [по электронной почте защищен] обозначает тот же адрес доставки, что и [электронная почта защищена] . RFC   5233 Относится к этому соглашению как Subaddressing , но она также известна как плюс адресация , тегическая адресация или расширения почты . Это может быть полезно для помещения электронных писем для сортировки и для контроля спама.

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

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

Домен

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

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

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

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

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

Примеры

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

• [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] (Бангифицированный маршрут хоста, используемый для почтовых рассеяний UUCP)
• "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com (Включите персонаж, не являющийся буквами, и множественные AT SIGN , первый цитируется двойным)
• user%[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 (Подчеркивается не допускается в доменной части)

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, в дополнение к домену на высшем уровне, правительство Индии в 2011 году Получил одобрение для ".bharat" (от Бхарата Ганараджья ), написанного в семи разных сценариях Для использования Гуджрати, Маратхи, Бангали, Тамильским, Телугу, Пенджаби и ораторами урду. Индийская компания XGenPlus.com утверждает, что является первым в мире поставщиком почтовых ящиков EAI, и правительство Раджастхана в настоящее время предоставляет бесплатную учетную запись электронной почты на домене राजस्थान.भारत для каждого гражданина штата. Ведущий медиа -домик Раджастхан Патрика запустил свой домен IDN पत्रिका.भारत с контактной электронной почтой.

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

• Латинский алфавит с диакликой : ele [электронная почта защищена]
• Греческий алфавит : Δοκιμή@παράΔειγμα. Δοκιμή
• Традиционные персонажи подбородка : я покупаю @hongkong
• Японские персонажи : Ниномия@Курокава
• Кириллические символы : meDVEDAH@S-BALALALAйCOй.RPE
• Деванагари персонажи : संपा@डाटामेल.भारत

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

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

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

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

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

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