Какие символы разрешены в адресе электронной почты?

Question

Я не спрашиваю о полной проверке электронной почты.

Я просто хочу узнать, какие символы разрешены в user-name и server частях электронного адреса.Это может быть упрощено, может быть, адреса электронной почты могут принимать другие формы, но мне все равно.Я спрашиваю только об этой простой форме: user-name@server (например, wild.wezyr@best-server-ever.com) и разрешенных символах в обеих частях.

Answer 1

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

IETF RFC 3696 является органом по этому вопросу, и с ним следует обращаться в разделе 3. Ограничения на адреса электронной почты на стр. 5:

Современные адреса электронной почты состоят из "локальной части", отделенной от «доменная часть» (полностью определенное доменное имя) с помощью знака «@». Синтаксис доменной части соответствует таковому в предыдущем раздел. Проблемы, выявленные в этом разделе в отношении фильтрации и списки имен применяются к доменным именам, используемым в контексте электронной почты, как Что ж. Доменное имя также можно заменить на IP-адрес в квадратные скобки, но эта форма настоятельно не рекомендуется, за исключением цели тестирования и устранения неисправностей.

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

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

  Abc\@def@example.com

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

  Fred\ Bloggs@example.com

Символ обратной косой черты может также использоваться для цитирования, например,

  Joe.\\Blow@example.com

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

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

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

Без кавычек локальные части могут состоять из любой комбинации
буквенные символы, цифры или любые специальные символы

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

точка (".") Также может появляться, но не может использоваться для начала или окончания локальная часть, а также не могут появиться два или более последовательных периода. Иными словами, любой графический (печатный) символ ASCII, кроме знак (@), обратный слеш, двойная кавычка, запятая или квадратные скобки может появляться без кавычек. Если какой-либо из этого списка исключен символы должны появляться, они должны быть в кавычках. Такие формы, как

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

действительны и видны довольно регулярно, но любой из символов Перечисленные выше разрешены.

Как и другие, я отправляю регулярное выражение для PHP и JavaScript для проверки адресов электронной почты:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

Answer 2

Как можно найти в этой ссылке в Википедии

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

• заглавные и строчные латинские буквы A до Z и a до z;

• цифры 0 до 9;

• специальные символы !#$%&'*+-/=?^_`{|}~;

• точка ., при условии, что он не является первым или последним символом, если он не заключен в кавычки, а также при условии, что он не появляется последовательно, если он не заключен в кавычки (например, John..Doe@example.com не разрешено, но "John..Doe"@example.com разрешено) ;

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

• комментарии допускаются с круглыми скобками в любом конце локальной части; например john.smith(comment)@example.com и (comment)john.smith@example.com эквивалентны john.smith@example.com.

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

Строка в кавычках может существовать как объект, разделенный точками в локальной части, или может существовать, когда самые внешние кавычки являются крайними символами локальной части (например, допускаются abc."defghi".xyz@example.com или "abcdefghixyz"@example.com. И наоборот , abc"defghi"xyz@example.com не является, как и abc\"def\"ghi@example.com). Строки и символы в кавычках, однако, обычно не используются. RFC 5321 также предупреждает, что «узлу, который ожидает получения почты, СЛЕДУЕТ избегать определения почтовых ящиков, где Local-часть требует (или использует) форму Quoted-string».

Локальная часть postmaster обрабатывается специально - она ​​не учитывает регистр и должна быть отправлена ​​администратору электронной почты домена. Технически все остальные локальные части чувствительны к регистру, поэтому jsmith@example.com и JSmith@example.com указывают разные почтовые ящики; однако многие организации рассматривают прописные и строчные буквы как эквивалентные.

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

Answer 3

Я создал это регулярное выражение в соответствии с рекомендациями RFC:

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

Answer 4

Gmail разрешает только знак + как специальный символ, а в некоторых случаях (.), Но любые другие специальные символы не разрешены в Gmail.В RFC говорится, что вы можете использовать специальные символы, но вам следует избегать отправки почты в Gmail со специальными символами.

Answer 5

Ответ (почти) ALL (7-битный ASCII).
Если правила включения "... разрешены при некоторых / любых / никаких условиях ..."

Просто взглянув на одно из нескольких возможных правил включения для разрешенного текста в части «текст домена» в RFC 5322 вверху страницы 17, мы находим:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

единственные три отсутствующих символа в этом описании используются в литерал домена [], чтобы сформировать пару в кавычках \ и символ пробела (% d32). При этом используется весь диапазон 32-126 (десятичный). Аналогичные требования появляются как «qtext» и «ctext». Многие управляющие символы также разрешены / использованы. Один список таких контрольных символов приведен на стр. 31 в разделе 4.1 RFC 5322 как obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

Все эти управляющие символы разрешены, как указано в начале раздела 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

И поэтому такое правило включения "просто слишком широкое". Или, в другом смысле, ожидаемое правило является «слишком упрощенным».

Answer 6

Для простоты я очищаю отправку, удаляя весь текст в двойных кавычках и связанные с ними двойные кавычки перед проверкой, добавляя кибошу при отправке адресов электронной почты на основе того, что запрещено. Тот факт, что кто-то может иметь Джона ... "* $ hizzle * Bizzle" .. Адрес Doe@whwhat.com не означает, что я должен разрешить его в моей системе. Мы живем в будущем, где, возможно, потребуется меньше времени, чтобы получить бесплатный адрес электронной почты, чем делать хорошую работу, вытирая задницу. И это не значит, что критерии электронной почты не намазаны рядом с входными данными, в которых указано, что разрешено, а что нет.

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

Недопустимое:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

В приведенном примере:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

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

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

Я не разрешаю электронные письма в моей системе, может быть, это просто выбрасывание денег. Но в 99,9% случаев люди просто поступают правильно и имеют электронную почту, которая не раздвигает границы соответствия, используя сценарии совместимости с крайними случаями. Будьте осторожны с регулярным выражением DDoS, это место, где вы можете попасть в беду. И это связано с третьим, что я делаю, я ограничиваю время, которое я готов обрабатывать по одному письму. Если ему нужно замедлить мою машину для проверки - она ​​не пройдет мимо логики конечной точки API входящих данных.

Редактировать: Этот ответ продолжал вызывать подозрения за то, что он был "плохим", и, возможно, он этого заслуживал. Может быть, все еще плохо, а может и нет.

Answer 7

В моем PHP я использую эту проверку

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

попробуй сам http://phpfiddle.org/main/code/9av6-d10r