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

"Françoise Lefèvre"@example.com

Я читаю RFC 5321 чтобы попытаться понять, что представляет собой действительный адрес электронной почты - и я, вероятно, делаю это намного сложнее, чем это должно быть-но это меня беспокоит.

               i.e., within a quoted string, any
               ASCII graphic or space is permitted
               without blackslash-quoting except
               double-quote and the backslash itself.

значит ли это, что ASCII расширенные наборы символов действительны в кавычках? Или это означает стандартная таблица ASCII только?

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

jQuery.validator.addMethod("ascii_email", function( value, element ) { 
    // In compliance with RFC 5321, this allows all standard printing ASCII characters in quoted text.
    // Unquoted text must be ASCII-US alphanumeric or one of the following: ! # $ % & ' * + - / = ? ^ _ ` { | } ~   
    // @ and . get a free pass, as this is meant to be used together with the email validator

    var result = this.optional(element) || 
        (
            /^[u002au002bu003du003fu0040u0020-u0027u002d-u002fu0030-u0039u0041-u005au005e-u007e]+$/.test(value.replace(/(["])(?:|.)*?/, "")) &&     
            /^[u0020-u007e]+$/.test(value.match(/(["])(?:|.)*?/, ""))   
        );
    return result;
}, "Invalid characters");

встроенная проверка плагина кажется довольно хорошей, за исключением ловли недопустимых символов. Из перечисленных тестовых случаев здесь он только запрещает комментарии, складывая пробелы и адреса, не имеющие TDL (т. е.: @localhost, @255.255.255.255) - все, без чего я могу легко жить.

10
email javascript jquery rfc

4 ответов

согласно этой странице MSDN расширенные символы ASCII в настоящее время недействительны, но есть предлагаемая спецификация, которая изменит это.

http://msdn.microsoft.com/en-us/library/system.net.mail.mailaddress(VS.90).aspx

важная часть здесь:

Томас Ли прав в том, что цитата локальная часть действительна в электронном письме адрес и некоторые почтовые адреса могут быть недопустимым, если не в строке с кавычками. Однако, персонажи другие вы упомянули таких, как умлаут и агавы нет в ASCII набор символов, они расширены ФОРМАТ ASCII. В RFC 2822 (и последующих RFC 5322 и 3696) dtext спецификация (разрешено в кавычках local части) позволяет только большинство значений ASCII (RFC 2822, раздел 3.4.1), который включает значения в диапазонах от 33-90 и 94-126. Было предложено RFC 5335 это позволит использовать символы, отличные от ascii в addr-spec, однако, это все еще помечены как экспериментальные и не поддерживается в почтовый адрес.

3

в этом RFC,ASCII означает US-ASCII, т. е. символы со значением больше 127 не допускаются. В качестве доказательства, вот некоторые цитаты из RFC 5321:

данные почты могут содержать любой из 128 кодов символов ASCII, [...]

[...]

системы не должны определять почтовые ящики таким образом, чтобы требовать использования в SMTP символов, отличных от ASCII (октетов с битом высокого порядка, установленным на один) или ASCII "управляющих символов" (десятичное значение 0-31 и 127). Эти символы не должны использоваться в командах MAIL или RCPT или других командах, требующих имен почтовых ящиков.

эти кавычки совершенно ясно подразумевают, что символы со значением больше 127 считаются non-ASCII. Поскольку такие символы явно запрещены в командах MAIL TO или RCPT, их нельзя использовать для адресов электронной почты.

таким образом, "Francoise Lefevre"@example.com является совершенно действительным адресом (в соответствии с RFC), тогда как "Françoise Lefèvre"@example.com нет.

4

технически да, но читаем дальше:

пока вышеуказанное определение для Локальная-часть относительно разрешительна,
для максимальной совместимости хост что ожидает получить почту избежать определения почтовым ящикам Local-часть требует (или использует) Quoted-строковая форма или где Локальная часть чувствительна к регистру.

...

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

1

спецификация HTML5 имеет интересно взять на себя вопрос о действительных адресов электронной почты:

допустимым адресом электронной почты является строка, соответствующая abnf production 1* (atext / ".") "@"ldh-str 1*( "."ldh-str), где atext определен в разделе 3.2.3 RFC 5322, а ldh-str-в разделе 3.5 RFC 1034.

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

0