Идентификатор электронной почты с дефисом в конце локальной части


19

Является ли это действительным электронным письмом, если электронное письмо имеет тире (-) в конце локальной части письма? Например,

an.unusual.email-@mydomain.com

Или, если обобщить, может ли какой-либо из этих символов ( Characters !#$%&'*+-/=?^_``{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126)) быть действительным в локальной части письма в начале и / или конце идентификатора письма?

Google говорит, что он недействителен, поэтому в настоящее время я предполагаю, что он также недействителен, хотя RFC исключает только символ [точка], начиная с и / или заканчивая локальной частью.

GMail Ошибка для вышеуказанного случая

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

https://social.technet.microsoft.com/Forums/ie/en-US/69f393aa-d555-4f8f-bb16-c636a129fc25/what-are-valid-and-invalid-email-address-characters


Хороший вопрос. Вы смотрели на эту тему вопросов и ответов о переполнении стека ? Много информации, большая часть которой устарела на данный момент, но все же хорошая отправная точка /
JakeGould

хорошая ссылочная ссылка, похоже, Google рассматривает это письмо как недействительное, в то время как у Microsoft нет проблем.
Джимсон Каннантхара Джеймс

1
Поделиться этим, так как вы открыли Google: Gmail игнорирует любые периоды в адресе электронной почты, поэтому, если ваш адрес электронной почты был «anunusualemail@gmail.com», вы также получили бы письмо, отправленное на «an.unusual.email@gmail.com». Он также игнорирует плюсы в конце адреса электронной почты: "anunusualemail+something@gmail.com".
Mowwwalker

1
В моем собственном почтовом сервисе я могу запретить букву "u" в именах пользователей. Да просто так.
Agent_L

Ответы:


60

Является ли это действительным электронным письмом, если электронное письмо имеет тире (-) в конце локальной части письма? [...] Google говорит, что он недействителен, поэтому на данный момент я предполагаю, что он также недействителен, хотя RFC исключает только символ [точка], начиная с и / или заканчивая локальной частью.

Это действительно. Вы только видите, что Google отклонил его, потому что он выполняет совершенно другую проверку - у них есть свои собственные политики относительно того, какой может быть локальная часть , как и у многих других провайдеров.


Google или кто-либо еще будет обязан принимать все возможные действительные адреса электронной почты только в том случае, если форма фактически запрашивает существующий действительный адрес электронной почты (возможно, от поставщика). Например, было бы ошибкой, если бы поле G: To: / Cc: G отклонило допустимый адрес.

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

Или, другими словами, определение разрешенных символов только для «локальной части» означает, что SMTP-серверы почтовых приложений должны принимать такие адреса в заголовках RFC 822 и командах SMTP - но это ничего не говорит о возможности создания таких почтовых ящиков. (Действительно, когда были написаны ранние RFC по электронной почте, и большинство почтовых ящиков все еще были привязаны к учетным записям на уровне ОС, их имена имели схожие или даже более строгие ограничения).

Например, эта часть RFC 5321 (раздел 4.1.2, ниже ABNF) явно говорит о том, что принимающему хосту разрешено и действительно должно быть гораздо более строгое ограничение на имена его собственных почтовых ящиков:

Хотя приведенное выше определение для Local-part является относительно разрешающим, для максимальной функциональной совместимости хосту, который ожидает получения почты, СЛЕДУЕТ избегать определения почтовых ящиков, где Local-часть требует (или использует) форму Quoted-string или где Local-part имеет значение case , чувствительные.

Таким образом, хотя синтаксически anunusualemail-@gmail.com это допустимо, само по себе это не означает, что Google должен позволять вам его создавать.


6
В качестве интересного примечания Google игнорирует периоды в адресах электронной почты ( gmail.googleblog.com/2008/03/… ), которые также не указаны в RFC. Таким образом, myname@gmail.com отправляется в то же место, что и my.name@gmail.com или myname@gmail.com.
childofsoong

4
@JimsonKannantharaJames В общем, если вы хотите проверить, является ли электронная почта действительной, вы должны отправить электронное письмо на этот адрес и заставить пользователя принять меры. Любые проверки, основанные только на синтаксисе адреса, должны просто поймать, что пользователь делает опечатки.
Майкл Миор

1
@ grawity О, я знаю - я комментировал, чтобы привести пример другой вещи, которая не указана в RFC, но разрешена.
childofsoong

1
@ user71659 Если вы неправильно экранируете управляющие символы там, где это необходимо, у вас есть большая проблема. В конечном счете, электронное письмо было введено пользователем, и пользовательский ввод всегда должен считаться опасным. Предполагая, что некоторые поля в вашей базе данных безопасны, потому что некоторые правила проверки могут быть довольно опасными. Что происходит, когда несколько месяцев спустя кто-то еще заполняет это поле из другой формы, которая не имеет такой же проверки?
Майкл Миор

2
@ user71659 вы смешиваете две разные проблемы и запутываете аргументы. MichaelMior совершенно правильно утверждать , что для проверки , что адрес электронной почты существует , то вы будете иметь , чтобы отправить письмо по этому адресу , который требует вмешательства пользователя.
kumarharsh

7

G Suite (формально Google Apps для вашего домена) допускает дефисы (тире) в адресах электронной почты, даже в качестве последнего символа.

Имена пользователей могут содержать буквы (az), цифры (0-9), тире (-), подчеркивания (_), апострофы (') и точки (.).

Источник: имя и пароль

Как вы заметили, Gmail не допускает дефисы в адресах электронной почты.

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