Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Транспорт сообщений [ править ]

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

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

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

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

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

Синтаксис [ править ]

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

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

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

Локальная часть [ править ]

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

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

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

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

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

Обратите внимание, что некоторые почтовые серверы поддерживают распознавание подстановочных знаков локальных частей, обычно символов после плюса и реже знаков после минуса, поэтому fred + bah @ domain и fred + foo @ domain могут оказаться в том же почтовом ящике, что и fred + @ domain. или даже как fred @ domain. Это может быть полезно для пометки писем для сортировки (см. Ниже) и для борьбы со спамом. [7] Скобки {и }также используются таким образом, хотя и реже. [ необходима цитата ]

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

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

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

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

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

Домен [ править ]

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

  • прописные и строчные латинские буквы Ato Zи ato 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.com , example.net и example.org .

Примеры [ править ]

Действительные адреса электронной почты
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected](может попасть во [email protected]входящие в зависимости от почтового сервера)
[email protected] (однобуквенная местная часть)
[email protected]
test/[email protected] (косая черта - печатный символ и разрешена)
admin@mailserver1(локальное доменное имя без TLD , хотя ICANN настоятельно не рекомендует использовать адреса электронной почты без точек [10] )
[email protected](см. Список Интернет-доменов верхнего уровня )
" "@example.org (пробел между кавычками)
"john..doe"@example.org (двойная точка в кавычках)
[email protected] (bangified host route, используемый для почтовых программ uucp)
user%[email protected] (% экранированный маршрут почты на [email protected] через example.org)
[email protected] (локальная часть, оканчивающаяся не буквенно-цифровым символом из списка допустимых печатных символов)


Недействительные адреса электронной почты
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_underscore@but_its_not_allowed_in_this_part.example.com (Подчеркивание недопустимо в доменной части)
QA[icon]CHOCOLATE[icon]@test.com (символы символов)

Общая семантика локальной части [ править ]

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

Нормализация локальной части [ править ]

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

Субадресация[ редактировать ]

Некоторые почтовые службы поддерживают тег, включенный в локальную часть, так что адрес является псевдонимом префикса локальной части. Например, адрес [email protected] обозначает тот же адрес доставки, что и [email protected] . RFC 5233, [13] называет это соглашение субадресацией , но оно также известно как добавочная адресация , тегированная адресация или почтовые расширения .

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

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

На практике проверка формы на некоторых веб-сайтах может отклонять такие символы, как «+» в адресе электронной почты, неправильно обрабатывая их как недопустимые символы. Это может привести к тому, что неправильный пользователь получит электронное письмо, если "+" автоматически удален веб-сайтом без каких-либо предупреждений или сообщений об ошибках. Например, электронное письмо, предназначенное для введенного пользователем адреса электронной почты [email protected], могло быть неправильно отправлено на [email protected]. В других случаях может возникнуть неудовлетворительное взаимодействие с пользователем, если некоторые части сайта, такие как страница регистрации пользователя, допускают использование символа «+», а другие части, такие как страница для отказа от подписки на список рассылки сайта, - нет.

Подтверждение и проверка [ править ]

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

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

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

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

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

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

Интернационализация [ править ]

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

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

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

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

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

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

Примеры интернационализации [ править ]

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

  • Латинский алфавит с диакритическими знаками : Pelé@example.com
  • Греческий алфавит : δοκιμή@παράδειγμα.δοκιμή
  • Традиционные китайские иероглифы : 我 買 @ 屋企. 香港
  • Японские иероглифы : 二 ノ 宮 @ 黒 川. 日本
  • Кириллические символы : медведь@с-балалайкой.рф
  • Персонажи деванагари : संपर्क@डाटामेल.भारत

Поддержка интернационализации [ править ]

  • Почтовая программа Postfix поддерживает интернационализированную почту с 08 февраля 2015 года со стабильной версией 3.0.0. [39]
  • Google поддерживает отправку электронных писем в и из интернационализированных доменов, но не позволяет регистрировать адреса электронной почты, отличные от ASCII. [40]
  • Microsoft добавила аналогичные функции в Outlook 2016 [41]
  • DataMail запускает международную поддержку электронной почты для 8 индийских языков с помощью платформы электронной почты XgenPlus в Индии. [42]

Документы стандартов [ править ]

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

См. Также [ править ]

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

Заметки [ править ]

  1. ^ Иногда имя пользователя, но не всегда.
  2. ^ Написано Дж. Кленсином, автором RFC 5321

Ссылки [ править ]

  1. ^ J. Klensin (октябрь 2008). «Общие принципы синтаксиса и модель транзакции» . Простой протокол передачи почты . п. 15. сек. 2.4. DOI : 10,17487 / RFC5321 . RFC 5321 . Локальная часть почтового ящика ДОЛЖНА обрабатываться с учетом регистра.
  2. ^ J. Klensin (октябрь 2008). «Общие принципы синтаксиса и модель транзакции» . Простой протокол передачи почты . п. 15. сек. 2.4. DOI : 10,17487 / RFC5321 . RFC 5321 . Однако использование чувствительности к регистру локальных частей почтового ящика препятствует взаимодействию и не рекомендуется.
  3. ^ "... вы можете добавлять или удалять точки с почтового адреса без изменения фактического адреса назначения; и все они попадут в ваш почтовый ящик ..." , Google.com
  4. ^ Klensin, J. (октябрь 2008). «Предельные и минимальные размеры» . Простой протокол передачи почты . IETF . сек. 4.5.3.1. DOI : 10,17487 / RFC5321 . RFC 5321 .
  5. ^ a b Кленсин, Дж. (февраль 2004 г.). RFC 3696 . IETF . DOI : 10,17487 / RFC3696 . Проверено 1 августа 2017 .: §3
  6. ^ Klensin, J. (октябрь 2008). RFC 5321 . IETF . сек. 4.5.3.1.1. DOI : 10,17487 / RFC5321 . Проверено 1 августа 2019 .
  7. ^ «Отправлять электронные письма с другого адреса или псевдонима - использовать псевдонимы Gmail» . Справка Gmail . Архивировано из оригинального 7 -го декабря 2019 года . Проверено 13 декабря 2019 .
  8. ^ «Зарегистрируйтесь в Windows Live» . Проверено 26 июля 2008 .. Однако фраза скрыта, поэтому нужно либо проверить наличие недопустимого идентификатора, например, me # 1 , либо прибегнуть к альтернативному отображению, например, без стиля или к исходному виду, чтобы прочитать ее.
  9. ^ «Символы в локальной части адреса электронной почты» . Проверено 30 марта 2016 .
  10. ^ «Новые доменные имена gTLD без точки запрещены» . www.icann.org . ICANN . Проверено 23 марта 2020 года .
  11. ^ Учитываются ли в адресах электронной почты регистр? Хайнц Чабичер
  12. ^ "Получение чужой почты" . google.com .
  13. ^ «Сетчатая фильтрация электронной почты: расширение подадреса» . IETF . Проверено 9 февраля 2019 года .
  14. ^ «Обзор системы сообщений Эндрю» (PDF) .
  15. ^ "Использование псевдонима адреса" . google.com .
  16. ^ «Одноразовые адреса в Yahoo Mail - Yahoo Help - SLN3523» . help.yahoo.com .
  17. ^ "Outlook.com также поддерживает более простые" + "псевдонимы электронной почты" . В Windows . Архивировано 20 февраля 2014 года.CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
  18. ^ «Адреса и псевдонимы» . protonmail.com .
  19. ^ «Плюс адресация и адресация субдоменов» . www.fastmail.com . Архивировано 6 октября 2020 года . Проверено 6 октября 2020 .
  20. ^ "FAQ postale.io по подадресации" . postale.io . Архивировано 6 октября 2020 года . Проверено 6 октября 2020 .
  21. ^ "Могу ли я использовать [email protected] с моей учетной записью Pobox?" . helppot.pobox.com . nd Архивировано из оригинала 2020-10-03 . Проверено 3 октября 2020 . Pobox поддерживает использование «+ anystring» (плюс расширения) с любым адресом.
  22. ^ "MeMail" . www.memail.com . Проверено 6 октября 2020 .
  23. ^ a b «Dot-Qmail, Контроль доставки почтовых сообщений» . Архивировано из оригинального 26 января 2012 года . Проверено 27 января 2012 года .
  24. ^ Подоконник, Дэйв. «4.1.5. Добавочные адреса» . Жизнь с qmail . Проверено 27 января 2012 года .
  25. ^ «Параметры конфигурации Postfix» . postfix.org .
  26. ^ "Параметры конфигурации Exim", "local_part_suffix " " . exim.org .
  27. ^ Джина Трапани (2005) "Мгновенные одноразовые адреса Gmail"
  28. ^ «Как Domino форматирует Интернет-адрес отправителя в исходящих сообщениях» . Центр знаний IBM . Проверено 23 июля 2019 года .
  29. ^ «Передовые методы работы с отправителями M3AAWG, версия 3» (PDF) . Рабочая группа по обмену сообщениями, вредоносным программам и мобильным устройствам . Февраль 2015 . Проверено 23 июля 2019 года .
  30. ^ Методы проверки и подтверждения для обеспечения качества адресов электронной почты , Ян Хорныч, 2011, Оксфордский университет.
  31. ^ «4.10 Формы - HTML5» . w3.org .
  32. ^ "Страницы статуса Eai" . Интернационализация адресов электронной почты (активная рабочая группа) . IETF. 17 марта 2006 - 18 марта 2013 . Проверено 26 июля 2008 года .
  33. ^ "Интернационализация адресов электронной почты (eai)" . IETF . Проверено 30 ноября 2010 года .
  34. ^ «2011-01-25 - Утверждение делегирования семи доменов верхнего уровня, представляющих Индию на разных языках - myICANN.org» . features.icann.org .
  35. ^ «Интернационализированные доменные имена (IDN) | Registry.In» . Registry.in . Проверено 17 октября 2016 .
  36. ^ «Теперь получите свой адрес электронной почты на хинди - The Economic Times» . The Economic Times . Проверено 17 октября 2016 .
  37. ^ «Всеобщее признание в Индии» .
  38. ^ "देश में पहला, प्रदेश के हर नागरिक के लिए मुफ्त-वॉल्ट और ई-मेल की सुविधा शुरू - वसुन्धरा राजे" . वसुन्धरा राजे (на хинди). 2017-08-18 . Проверено 20 августа 2017 .
  39. ^ " ' Стабильный выпуск Postfix 3.0.0' - MARC" . marc.info .
  40. ^ «Первый шаг к более глобальной электронной почте» . Официальный блог Google . Проверено 6 августа 2014 .
  41. ^ «Что нового в Outlook 2016 для Windows» , support.office.com
  42. ^ «DataMail запускает бесплатную лингвистическую службу электронной почты на восьми индийских языках» . Tech2 . Проверено 25 ноября 2017 .

Внешние ссылки [ править ]

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