Какие символы разрешены в email?

Question

[My1Name]

Какие символы из нижеприведённого массива разрешены, и какие не учтены для использования в e-mail адресе?

String [] emailEexcludeSymbols = {"&","?","=","+","#","%","}","{","\\","[","]","|","^","<",">","*","$","!","~","`",",",";","(",")","'","\""};

Comments

[Василий Банников]

https://habr.com/ru/articles/224623/
В разных частях адреса разрешены разные символы, и вроде даже зависит от контекста.
Некоторые провайдеры ещё и не полностью эту спецификацию поддерживают.

[pfg21]

есть регексп для проверки корректности емайла - погугли.
только увидев не пугайся размеров :)

[My1Name]

Василий Банников, Нет смысла что либо запрещать?

[Adamos]

My1Name, например, у меня сейчас на столе лежит письмо (бумажное) от потенциального пользователя, который не смог зарегистрироваться на сайте только потому, что указывал почту через & вместо @. Человеку 76 годиков, он путает. Запрещать - имхо, неверно сказано. Стоит указывать, что такого символа в почте не должно быть.

[My1Name]

Adamos,

Стоит указывать, что такого символа в почте не должно быть.

Это понятно. Вопрос в том, каких символов не должно быть? Было бы здорово написать их все в один список.

[Василий Банников]

Adamos, если пользователь написал почту через & вместо @, то можно просто сказать, что его почта невалидна по принципу "в почте обязательно есть @"

[Akina]

Для имени ящика в домене (часть до символа @, local-part of an email address) есть различные ограничения, в зависимости от того, является оно квотированным (обрамлённым символами двойной кавычки) или нет, и используется ли SMTPUTF8.

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

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

Если всё же есть намерение создать свой верификатор, рекомендую начать со статьи "Email address" в англоязычной вики. К тому же там достаточно неплохо собраны ссылки на необходимые материалы.

[Akina]

Василий Банников,

если пользователь написал почту через & вместо @, то можно просто сказать, что его почта невалидна по принципу "в почте обязательно есть @"

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

[Василий Банников]

My1Name,
Разрешённые, получается
Все буквы латинского алфавита, цифры от 0 до 9, спецсимволы "!#$%&'*+-/=?^_`{|}~"(),:;<>@[\]", кавычки, пробел, круглые скобки, точка, табуляция, любой печатаемый символ ascii (даже псевдографика), могут быть переносы строк, и даже несколько собак, international characters above U+007F
И это только про "local part"

The local-part of the email address may be unquoted or may be enclosed in quotation marks.

If unquoted, it may use any of these ASCII characters:

uppercase and lowercase Latin letters A to Z and a to z
digits 0 to 9
printable characters !#$%&'*+-/=?^_`{|}~
dot ., provided that it is not the first or last character and provided also that it does not appear consecutively (e.g., [e-mail] is not allowed).

If quoted, it may contain Space, Horizontal Tab (HT), any ASCII graphic except Backslash and Quote and a quoted-pair consisting of a Backslash followed by HT, Space or any ASCII graphic; it may also be split between lines anywhere that HT or Space appears. In contrast to unquoted local-parts, the addresses ".John.Doe"@example.com, "John.Doe."@example.com and "John..Doe"@example.com are allowed.

The maximum total length of the local-part of an email address is 64 octets.[8]

Space and special characters "(),:;<>@[\] are allowed with restrictions (they are only allowed inside a quoted string, as described in the paragraph below, and in that quoted string, any backslash or double-quote must be preceded once by a backslash);
Comments are allowed with parentheses at either end of the local-part; e.g., john.smith(comment)@example.com and (comment)[e-mail] are both equivalent to [e-mail].
In addition to the above ASCII characters, international characters above U+007F, encoded as UTF-8, are permitted by RFC 6531 when the EHLO specifies SMTPUTF8, though even mail systems that support SMTPUTF8 and 8BITMIME may restrict which characters to use when assigning local-parts.

A local-part is either a Dot-string or a Quoted-string; it cannot be a combination. Quoted strings and characters, however, are not commonly used.[citation needed] RFC 5321 also warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form".

The local-part postmaster is treated specially—it is case-insensitive, and should be forwarded to the domain email administrator. Technically all other local-parts are case-sensitive, therefore [e-mail] and [e-mail] specify different mailboxes; however, many organizations treat uppercase and lowercase letters as equivalent. Indeed, RFC 5321 warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where ... the Local-part is case-sensitive".

Despite the wide range of special characters which are technically valid, organisations, mail services, mail servers and mail clients in practice often do not accept all of them. For example, Windows Live Hotmail only allows creation of email addresses using alphanumerics, dot (.), underscore (_) and hyphen (-).[9] Common advice is to avoid using some special characters to avoid the risk of rejected emails.[10]

According to RFC 5321 2.3.11 Mailbox and Address, "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain of the address". This means that no assumptions can be made about the meaning of the local-part of another mail server. It is entirely up to the configuration of the mail server.

Interpretation of the local-part is dependent on the conventions and policies implemented in the mail server. For example, case sensitivity may distinguish mailboxes differing only in capitalization of characters of the local-part, although this is not very common. Gmail ignores all dots in the local-part of a @gmail.com address for the purposes of determining account identity.

[Василий Банников]

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

[Василий Банников]

Akina, в случае с регистрацией на сайте нам внутридоменная пересылка точно не нужна)

[Adamos]

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

[My1Name]

Adamos,

нетривиальная опасность: настроить более широкие ограничения по адресу, чем у почтового сервера провайдера

Судя по количеству примеров и рекомендаций в интернете, я ориентируюсь на SMTP-сервер GMail

Answer 1

[Василий Банников]

Список формально разрешённых символов тебе ничего не даст, тк по спецификации - это практически все печатаемые ascii-символы + ещё какие-то международные символы из юникода, но практически никто на 100% спецификации не следует.

Лучше ограничить себя тем, что может отправить твой почтовый сервер:
1. Сделай обязательным наличие собаки и каких-то (любых) символов до и после неё.
2. Сделай попытку отправить письмо на эту почту и обязуй пользователя перейти по ссылке из письма для продолжения регистрации.

Answer 2

[Aetae]

Всё фигня, вот такой регулярки достаточно: /^\S+@\S+$/. Да это чуть шире чем можно, но именно что чуть, нет никакого смысла заморачиваться с чем-то большим. Не пройдёт письмо один раз из миллиона, ну и ладно.

Answer 3

[Dimonchik]

типичный регексп такой
[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}
очевидно, что идут лесом не латинские буквы, например

если очень хочется к основам - RFC вот https://datatracker.ietf.org/doc/html/rfc5322 ,
но не надейся - адреса там ссылаются в том числе на другие протоколы, хе-хе

поэтому где-то можно найти примерно такое:

• Латинские буквы в верхнем и нижнем регистре: A-Z и a-z
• Цифры от 0 до 9
• Специальные символы: ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• Точка . (не первый или последний символ или не повторяется)
• Двойная кавычка " (только в локальной части и должна быть экранирована обратным слешем )
• Пробел и специальные символы ( ) , : ; < > @ [ ] (только в локальной части и должны быть заключены в двойные кавычки)

Comments

[Adamos]

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

[Dimonchik]

Adamos, я регекп для этого и привел

но мы же не знаем чего ТСу надо - вот он исключил, например, плюс (+), а плюс в Gmail сплошь и рядом
кавычки, внезапно и даже пробелы - тоже нередки

Answer 4

[CityCat4]

Использую вот такую регулярку (не моя, често спиз....я в тырнете)

_regexp="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$"