Проверка поля ввода email.

Какие проверки поля ввода email надо сделать (email text box)?
Спасибо.

валидация email http://software-test...um/topic/18560/

Взято из en.wikipedia.org

Часть адреса до символа @ (логин) может включать любые из этих символов:

• Английские буквы верхнего и нижнего регистра (a–z, A–Z)
• Цифры от 0 до 9
• Символы ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• Символ . (точка) при условии, что он не первый и не последний, а также, если он не повторяется больше одного раза подряд (например, John..Doe@example.com)

Общая длина логина может быть вплоть до 64 символов.

Часть адреса после символа @ (домен) может включать любые из этих символов:

• Английские буквы нижнего регистра (a–z)
• Цифры от 0 до 9
• Символ - (тире)
• Символ . (точка)

Части домена, разделенные точкой не должны начинаться с цифры или тире и не должны заканчиватся тире, а также они должны иметь длину от 1 до 63 символов. Общая длина домена должна иметь максимум 253 символа. Доменная часть может быть IP-адресом, заключенным в квадратные скобки (например, jsmith@[192.168.2.1]).

Только я вот не пойму, почему на всех емейл сервисах, которые я нашел, нет подчинения этим стандартам. По-че-му? Может плохо искал? Могу предположить, что уменьшение количества символов в логине сделано для оптимизации размеров баз данных. А символы причем? Может следует изменить эти стандарты? Как же тогда производить тестирование или даже как кодировать? Выбрать самый требовательный к адресам сервис и по нему ориентироваться? И я так понимаю, что если какая-то форма не пропускает некоторые валидные емейлы из-за недопустимости адреса, то это не баг?

Хорошая статья на эту тему: I Knew How To Validate An Email Address Until I Read The RFC

Только я вот не пойму, почему на всех емейл сервисах, которые я нашел, нет подчинения этим стандартам. По-че-му? Может плохо искал? Могу предположить, что уменьшение количества символов в логине сделано для оптимизации размеров баз данных. А символы причем? Может следует изменить эти стандарты? Как же тогда производить тестирование или даже как кодировать? Выбрать самый требовательный к адресам сервис и по нему ориентироваться? И я так понимаю, что если какая-то форма не пропускает некоторые валидные емейлы из-за недопустимости адреса, то это не баг?

Интересно, сколько раз надо написать одно и тоже...
RFC - стандарт. Если вы пишете почтовый сервер - будьте добры, соблюдать все это.
Если ваша веб-програмулька не понимает всех возможных вариантов почтовых адресов - то это ХОРОШО!
В этом случае ваша программа не протеворечит этому стандарту. Но в ней будет меньше кода, и меньше ошибок, от исправления которых не станет лучше ни одному живому существу на планете.

Да и это нафиг никому не нужно, поддерживать все эти возможные адреса. И если найдется идиот с ненормальным адресом в 64 символа (или сколько их там) на домене второго уровня - то пусть он идет лесом мимо вашей программы со своим адресом.

Если вы не тестируете почтовый сервер (ну и возможно клиент тоже) - то использование всяких экзотических емэйлов - (а) трата времени и (б) создание ненужных записей в трэкере. Если бы я был программистом и ко мне бы пришли и сказали "first.(")middle.last(")@[IPv6:::12.34.56.78]" - не работает, согласно RFC, давай чинить. Я бы послал куда подальше.

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

PS: кстати [IPv6:::12.34.56.78] - нихрена невалидный Ipv6 адрес - очередной булшит

Большое всем спасибо за ответы!
:)