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

"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) || 
        (
            /^[\u002a\u002b\u003d\u003f\u0040\u0020-\u0027\u002d-u002f\u0030-\u0039\u0041-\u005a\u005e-\u007e]+$/.test(value.replace(/(["])(?:\\\1|.)*?\1/, "")) &&     
            /^[\u0020-\u007e]+$/.test(value.match(/(["])(?:\\\1|.)*?\1/, ""))   
        );
    return result;
}, "Invalid characters");

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

Ответ 1

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

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

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

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

Ответ 2

В этом 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 не является.

Ответ 3

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

В то время как вышеприведенное определение для Локальная часть относительно разрешительная,
для максимальной совместимости, хост который рассчитывает получить почту СЛЕДУЕТ избегать определения почтовых ящиков, где Локальная часть требует (или использует) Форма в виде котировки или где Локальная часть чувствительна к регистру.

...

Системы НЕ ДОЛЖНЫ определять почтовые ящики в таким образом, чтобы потребовать использования в SMTP символов, отличных от ASCII.

Ответ 4

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

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

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