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


641

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

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


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

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

9
Предыдущий вопрос, касающийся того же материала: stackoverflow.com/questions/760150/ . Печально то, что, несмотря на то, что этот вопрос почти на 8 месяцев старше этого, на старый вопрос ответы гораздо лучше. Почти все ответы ниже были уже устаревшими, когда они были первоначально размещены. Смотрите запись в Википедии (и не волнуйтесь, она имеет соответствующие официальные ссылки ).
Джон Y

10
В отличие от нескольких ответов, пробелы будут разрешены в локальной части адреса электронной почты, если в кавычках. "hello world"@example.comдействует.
user253751

3
@LaraRuffleColes - для Gmail, когда вы создаете учетную запись электронной почты, она не позволяет создавать адреса, содержащие знак «+». Знак «+» («Плюс-адресация») позволяет любому, у кого есть адрес Gmail, добавить знак «+», за которым следует «строка» в конце имени пользователя, чтобы создать «альтернативный» («псевдоним») адрес электронной почты. использовать для своей учетной записи. Пример: "example@gmail.com", "example+tag@gmail.com". Типичным (и, вероятно, «основным») использованием этого является возможность создавать псевдонимы адресов электронной почты для вашей учетной записи, которые позволяют вам отмечать и фильтровать входящие сообщения электронной почты, теоретически фильтруемые отправителем.
Кевин Феган

Ответы:


797

См. RFC 5322: Формат интернет-сообщения и, в меньшей степени, RFC 5321: Простой протокол пересылки почты .

RFC 822 также охватывает адреса электронной почты, но в основном имеет дело со своей структурой:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

И, как обычно, в Википедии есть достойная статья об адресах электронной почты :

Локальная часть адреса электронной почты может использовать любой из этих символов 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 с 2012 года вы можете использовать вышеупомянутые международные символыU+007F , закодированные как UTF-8, как описано в спецификации RFC 6532 и объяснено в Википедии . Обратите внимание, что по состоянию на 2019 г. эти стандарты все еще помечены как предлагаемые, но постепенно внедряются. Изменения в этой спецификации по существу добавили международные символы в качестве допустимых буквенно-цифровых символов (atext), не затрагивая правила для разрешенных и запрещенных специальных символов, таких как !#и @:.

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

domainЧасть определяется следующим образом :

Стандарты Интернета (Запрос на комментарии) для протоколов санкционировать , что компонент имя хост метка может содержать только ASCII букву aчерез z(в зависимости от регистра), цифры 0через 9и дефис ( -). Исходная спецификация имен хостов в RFC 952 требовала, чтобы метки не могли начинаться с цифры или с дефиса и не должны заканчиваться дефисом. Однако последующая спецификация ( RFC 1123 ) разрешила меткам имен хостов начинаться с цифр. Другие символы, знаки пунктуации и пробелы не допускаются.


15
@WildWzyr, это не так просто. Адреса электронной почты имеют много правил для того, что разрешено. Проще обратиться к спецификации, чем перечислить их все. Если вам нужен полный Regex, проверьте здесь, чтобы понять, почему это не так просто: регулярные выражения.info/email.html
Дэн Герберт,

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

15
@WildWezyr Хорошо, символ полной остановки разрешен в локальной части. Но не в начале или в конце. Или с другой полной остановкой. Таким образом, ответ НЕ так прост, как просто список разрешенных символов, есть правила относительно того, как эти символы могут использоваться - .ann..other.@example.comэто не действительный адрес электронной почты, но ann.other@example.com, хотя оба используют одни и те же символы.
Марк Пим

14
Также помните, что при появлении интернационализированных доменных имен список разрешенных символов будет взорван.
Чинмай Канчи

50
Это больше не правильный ответ из-за интернационализированных адресов. Смотри ответ Мейсона.
ZacharyP

329

Осторожно! В этой теме есть куча знаний (вещи, которые раньше были правдой, а теперь нет).

Чтобы избежать ложноположительных отклонений фактических адресов электронной почты в текущем и будущем мире и из любой точки мира, вам необходимо знать хотя бы концепцию высокого уровня RFC 3490 , «Интернационализация доменных имен в приложениях (IDNA)». Я знаю, что люди в США и А часто не задумываются об этом, но они уже широко распространены и быстро растут во всем мире (в основном это не английский язык).

Суть в том, что теперь вы можете использовать адреса, такие как mason @ 日本 .com и wildwezyr@fahrvergnügen.net. Нет, это еще не совместимо со всем (как многие сетовали выше, даже простые адреса qmail-style + идент часто ошибочно отклоняются). Но есть RFC, есть спецификация, теперь она поддерживается IETF и ICANN, и, что более важно, существует большое и растущее число реализаций, поддерживающих это улучшение, которые в настоящее время находятся в эксплуатации.

Я сам ничего не знал об этой разработке, пока не вернулся в Японию и не начал видеть адреса электронной почты, такие как hei @ や る .ca и URL-адреса Amazon, например:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ス - デ ジ タ ル カ メ ラ - ポ ー タ ブ ル オ ー デ ィ オ / б / исх = topnav_storetab_e т.е. = UTF-8 & узел = 3210981

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

Так что я не говорю, что это не хлопотно, но полный список символов, «разрешенных при некоторых / любых / никаких условиях», - это (почти) все символы на всех языках. Если вы хотите «принять все действительные адреса электронной почты (и многие недействительные тоже)», вам необходимо принять во внимание IDN, что в основном делает бесполезным подход на основе символов (извините), если только вы сначала не преобразовали интернационализированные адреса электронной почты в Punycode .

После этого вы можете следовать (большей части) совету выше.


17
Правильно; за кулисами доменные имена все еще просто ASCII. Но если ваше веб-приложение или форма принимает вводимые пользователем данные, тогда оно должно выполнять ту же работу, что и веб-браузер или почтовый клиент, когда пользователь вводит имя хоста IDN: преобразовать введенные пользователем данные в DNS-совместимую форму. Тогда подтвердите. В противном случае эти интернационализированные адреса электронной почты не пройдут проверку. (Конвертеры, подобные тому, который я связал, изменяют только те символы, которые не указаны в ASCII, которые им даны, поэтому их можно безопасно использовать на не интернационализированных адресах электронной почты (они только что возвращаются без изменений).)
Мейсон

2
Для разработчиков Javascript я сейчас исследую способы сделать это, и Punycode.js кажется наиболее полным и отточенным решением.
wwaawaw

5
Обратите внимание, что интернационализированная электронная почта (как определено в настоящее время) не преобразует адреса, отличные от ASCII, с использованием punycode или аналогичного, вместо этого расширяя большие части самого протокола SMTP для использования UTF8.
IMSoP

2
Я что-то упустил или это не отвечает на вопрос? Я читаю «другой ответ неправильный, вам нужно принять больше символов», но затем не в состоянии указать, какие дополнительные символы. Я также не мог (легко) увидеть в этом RFC, означает ли он все кодовые точки Unicode или только BMP.
Самуэль Хармер

3
Это похоже на правильный путь, чтобы быть правильным ответом. Могу поспорить, было бы гораздо больше голосов, если бы вы включили информацию о зарезервированных и разрешенных персонажах.
Шон

59

Формат адреса электронной почты: local-part@domain-part(не более 64 @ 255 символов, всего не более 256).

local-partИ domain-partможет иметь различный набор допустимых символов, но это еще не все, так как есть еще правила к нему.

Как правило, локальная часть может иметь следующие символы ASCII:

  • строчные буквы латинского алфавита: abcdefghijklmnopqrstuvwxyz,
  • прописные буквы латинского алфавита: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • цифры: 0123456789,
  • специальные символы: !#$%&'*+-/=?^_`{|}~,
  • точка: .(не первый или последний символ или повторяется, если не указано),
  • знаки пунктуации, такие как: "(),:;<>@[\](с некоторыми ограничениями),
  • комментарии: ()(допустимы в скобках, например (comment)john.smith@example.com).

Доменная часть:

  • строчные буквы латинского алфавита: abcdefghijklmnopqrstuvwxyz,
  • прописные буквы латинского алфавита: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • цифры: 0123456789,
  • дефис: -(не первый или последний символ),
  • может содержать IP-адрес в квадратных скобках: jsmith@[192.168.2.1]или jsmith@[IPv6:2001:db8::1].

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

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (однобуквенная локальная часть)
  • "much.more unusual"@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
  • example-indeed@strange-example.com
  • admin@mailserver1 (локальное доменное имя без домена верхнего уровня)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (пробел между кавычками)
  • example@localhost (отправлено с локального хоста)
  • example@s.solutions(см. Список интернет-доменов верхнего уровня )
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

И эти примеры недействительны:

  • Abc.example.com(без @персонажа)
  • A@b@c@example.com(только один @допускается вне кавычек)
  • a"b(c)d,e:f;gi[j\k]l@example.com (ни один из специальных символов в этой локальной части не допускается вне кавычек)
  • just"not"right@example.com (строки в кавычках должны быть разделены точкой или единственным элементом, составляющим локальную часть)
  • this is"not\allowed@example.com (пробелы, кавычки и обратная косая черта могут существовать, только если они находятся внутри строк в кавычках и им предшествует обратная косая черта)
  • this\ still\"not\allowed@example.com (даже если экранирован (ему предшествует обратная косая черта), пробелы, кавычки и обратная косая черта должны по-прежнему содержаться в кавычках)
  • john..doe@example.com(двойная точка перед @); (с оговоркой: Gmail позволяет это сделать)
  • john.doe@example..com(двойная точка после @)
  • действительный адрес с пробелом
  • действительный адрес с завершающим пробелом

Источник: адрес электронной почты в Википедии


Регламент Perl RFC2822 для проверки электронной почты:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

Полное регулярное выражение для адресов RFC2822 составило всего 3.7k.

Смотрите также: RFC 822 Парсер адресов электронной почты в PHP .


Формальные определения адресов электронной почты:

  • RFC 5322 (разделы 3.2.3 и 3.4.1, устаревшие RFC 2822), RFC 5321, RFC 3696,
  • RFC 6531 (разрешенные символы).

Связанные с:


5
В качестве дополнительного предупреждения потенциальным исполнителям этого регулярного выражения: не делайте этого. Просто убедитесь, что он соответствует формату, something@something.somethingи назовите это день.
Крис Соболевски

Хотя что-то подобное не
поддается

@ChrisSobolewski разрешить множественные вещи по обе стороны от '@'
Jasen

Я попытался реализовать это в postfix через таблицу доступа к pcre с ограничением check_recipient_access, сначала превратив 3 длинных pcres (со связанной страницы) в одну строку и расположив таким образом верхний и нижний хвосты: /^[...pcre ..] $ / DUNNO, затем добавляется последняя строка /.*/ REJECT, но она по-прежнему пропускает недействительные адреса электронной почты. Постфикс 3.3.0; Perl 5, версия 26, Subversion 1 (v5.26.1).
scoobydoo

3
Безумие говорю. Кто бы когда-либо использовал это в производстве. Есть точка, где регулярное выражение больше не должно использоваться. Это далеко за пределами этой точки.
Tomuxmon

22

В Википедии есть хорошая статья на эту тему , и официальная спецификация здесь . Из Википедии:

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

  • Прописные и строчные английские буквы (az, AZ)
  • Цифры от 0 до 9
  • Персонажи ! # $% & '* + - / =? ^ _ `{| } ~
  • Символ . (точка, точка, точка) при условии, что это не первый или последний символ, а также при условии, что он не появляется два или более раз подряд.

Кроме того, допускаются строки в кавычках (например, «John Doe» @ example.com), что позволяет использовать символы, которые в противном случае были бы запрещены, однако они не встречаются в обычной практике. RFC 5321 также предупреждает, что «узлу, который ожидает получать почту, СЛЕДУЕТ избегать определения почтовых ящиков, для которых локальная часть требует (или использует) форму Quoted-string».


@WildWezyr Допустимые имена хостов, которые могут быть IP-адресом, FQN или чем-то разрешаемым для хоста локальной сети.
JensenDied

Строки в кавычках были необходимы для прохождения через ворота, помните Banyan Vines?
Маккензм

13

Google делает интересную вещь с их адресами gmail.com. Адреса gmail.com допускают только буквы (az), цифры и точки (которые игнорируются).

например, pikachu@gmail.com совпадает с pi.kachu@gmail.com, и оба адреса электронной почты будут отправлены в один и тот же почтовый ящик. PIKACHU@gmail.com также доставляется в тот же почтовый ящик.

Таким образом, чтобы ответить на вопрос, иногда от исполнителя зависит, насколько много стандартов RFC они хотят соблюдать. Стиль адреса Google gmail.com совместим со стандартами. Они делают это таким образом, чтобы избежать путаницы, когда разные люди берут одинаковые адреса электронной почты, например

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

Ссылка на википедию - хорошая ссылка на то, что обычно разрешают адреса электронной почты. http://en.wikipedia.org/wiki/Email_address


2
Да, это отличный ответ о том, почему Gmail не позволяет СОЗДАТЬ электронные письма с этим. Но вы можете отправлять и получать электронные письма {john'doe}@my.serverбез проблем. Протестировано с hMail сервером тоже.
Петр Кула

Вы можете протестировать своего клиента, отправив электронное письмо на {piotr'kula}@kula.solutions- Если это работает, вы получите хороший автоответ от него. Иначе ничего не случится.
Петр Кула

3
Gmail следует RFC 6530 в том смысле, что каждый возможный адрес электронной почты, разрешенный Gmail, действителен в соответствии с RFC. Gmail просто выбирает дальнейшее ограничение набора допустимых адресов с помощью дополнительных правил, а также делает аналогичные адреса с точками в локальной части, за которыми необязательно следуют символы «+» и буквенно-цифровые символы, синонимичными.
Теему Лейсти

Google ограничивает критерии создания учетной записи ... Я предполагаю, что они очищают входящую строку учетной записи электронной почты с дополнительной "пунктуацией" и завершающим символом плюс псевдоним строки, чтобы почта могла быть перенаправлена ​​на соответствующую учетную запись. Очень просто. При этом они фактически не позволяют людям создавать адреса электронной почты просто-напросто, поэтому созданные действительные адреса часто проходят простые и самые сложные проверки.
BradChesney79

Это не просто gmail. Некоторые провайдеры имеют «ретранслирующие фильтры», которые отклоняют определенные строки в кавычках, особенно содержащие «=», как если бы они были разделителями. Это сделано для того, чтобы запретить пользователям настраивать шлюзы и вкладывать спам-адреса в приватную строку в кавычках. «@» допустимо, но «= @ =» недопустимо (считается).
Маккензм

12

Вы можете начать со статьи в Википедии :

  • Прописные и строчные английские буквы (az, AZ)
  • Цифры от 0 до 9
  • Персонажи ! # $% & '* + - / =? ^ _ `{| } ~
  • Символ . (точка, точка, точка) при условии, что это не первый или последний символ, а также при условии, что он не появляется два или более раз подряд.

11

Имя:

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

Сервер:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

4
Что о <>и []? Например, "()<>[]:,;@\\\"!#$%&'-/=?^_{} | ~ .a "@ example.org`?
kenorb

20
Пожалуйста, приведите источники. Без источников это выглядит как гипотеза.
Матье К.

15
Это устарело и, возможно, никогда не было правильным.
Джейсон Харрисон

9

Проверьте на @ и. а затем отправьте электронное письмо для проверки.

Я все еще не могу использовать свой адрес электронной почты .name на 20% сайтов в Интернете, потому что кто-то испортил их проверку электронной почты, или потому что это предшествует действию новых адресов.


9
Даже . не является строго необходимым; Я слышал, по крайней мере, об одном случае адреса электронной почты в домене верхнего уровня (в частности, ua). Адрес был <имя> @ua - без точек!

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

5

Короткий ответ: есть 2 ответа. Существует один стандарт того, что вы должны делать. то есть поведение, которое является мудрым и будет держать вас от неприятностей. Существует другой (гораздо более широкий) стандарт поведения, которое вы должны принять, не создавая проблем. Эта двойственность работает для отправки и приема электронной почты, но имеет широкое применение в жизни.

Для хорошего руководства по адресам, которые вы создаете; см .: http://www.remote.org/jochen/mail/info/chars.html

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


Ссылка исчезла. Какой контент был там?
ygoe

5

Хорошее чтение по этому вопросу .

Выдержка:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

1
Я задавался вопросом о «@» перед доменной частью. Можно ли это использовать?
Сайяфф Фарук

@SaiyaffFarouk согласно спецификации, да. Тем не менее, большинство почтовых провайдеров, скорее всего, не допустят это как часть собственной проверки
Люк Мадханга,

этот блог перечисляет Joe.\\Blow@example.comбез кавычек. Это действительно верно? Это не совсем понятно, учитывая ответы здесь, но я спрашиваю, потому что я видел (очень редкие) случаи строк электронной почты DNS SoA rname, которые содержат обратную косую черту.
wesinat0r

5

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

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

3

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

Локальная часть адреса электронной почты может использовать любой из этих символов 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 также предупреждает, что «узлу, который ожидает получать почту, СЛЕДУЕТ избегать определения почтовых ящиков, для которых локальная часть требует (или использует) форму Quoted-string».

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

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


0

Ответ (почти) 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». Многие управляющие символы также разрешены / использованы. Один список таких контрольных символов приведен в разделе 4.1 RFC 5322 на стр. 31 как 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 ....

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


0

Для простоты я очищаю отправку, удаляя весь текст в двойных кавычках и связанные с ними двойные кавычки перед проверкой, добавляя кибошу при отправке адресов электронной почты на основе того, что запрещено. Тот факт, что кто-то может иметь Джона ... "* $ hizzle * Bizzle" .. Адрес Doe@whever.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 входящих данных.

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


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

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

@vcarel - О, конечно. Проверка на стороне пользователя переднего плана сообщит им, какие правила (доступные во всплывающей подсказке) они нарушают. Вы правы - это общее мнение. Тем не менее, вопрос выше от кого-то, кто наверняка задает вопрос Y. Это руководство, и оно работает ... не только работает, но и работает хорошо. Я не разрешаю ерунду адресов электронной почты в моих системах, где я принимаю решения.
BradChesney79

@HoldOffHunger Я вижу, что общая идея выражена не так четко, как могла бы быть, я могу пересмотреть в другой день, когда у меня будет больше времени, чтобы лучше выразить это. Спасибо за понимание.
BradChesney79

-1

В моем 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


-1

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

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

1
Эта версия улучшает регулярные выражения, проверяя длину домена / поддоменов. Наслаждайтесь! ^ [\\ ш \\ \\ _ \\% # \\ $ \\ & \\ = \\ \ * \\ + \\ -.!? \\ / \\ ^ \ `\\ {\\ ??. | \\} \\ ~] + @ (: [\\ ш] (: [\\ ш \\ -] {0,61} [\\ ш]) (: \\ [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])?) *) $
Mau

-2

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.