Почтовые адреса чувствительны к регистру?

Я читал, что стандартная первая часть электронной почты чувствительна к регистру, однако я пытался отправить электронную почту name@example.com, Name@example.comи NAME@example.com- она ​​поступала в каждом случае.

Как почтовые серверы обрабатывают имена пользователей? Можно ли пропустить случай, и это сообщение не будет доставлено? Действительно ли очень важно использовать точно такой же регистр букв, который был написан при регистрации при указании вашего адреса электронной почты?

Из RFC 5321, раздел 2.3.11 :

Стандартное соглашение об именах почтовых ящиков определено как «local-part @ domain»; современное использование позволяет гораздо более широкий набор приложений, чем простые «имена пользователей». Следовательно, и из-за долгой истории проблем, когда промежуточные хосты пытались оптимизировать транспорт, изменяя их, локальная часть ДОЛЖНА интерпретироваться и назначаться семантикой только хостом, указанным в доменной части адреса.

Так что да, часть перед «@» может быть чувствительна к регистру, так как она полностью находится под контролем хост-системы. Однако на практике ни одна из широко используемых почтовых систем не различает разные адреса в зависимости от случая.

Однако часть после знака @ является доменом и в соответствии с RFC 1035 , раздел 3.1,

«Серверы имен и распознаватели должны сравнивать [домены] без учета регистра»

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

Я знаю, что это старый вопрос, но я просто хочу прокомментировать здесь: в какой-то степени адреса электронной почты чувствительны к регистру, большинство пользователей будет «очень неразумно» активно использовать адрес электронной почты, который требует прописных. Они скоро перестанут использовать адрес, потому что будут пропускать большую часть своей почты. (Если у них нет конкретной причины усложнять ситуацию, и они ожидают почту только от определенных отправителей, которых они знают.)

Это потому, что существуют несовершенные люди, а также несовершенное программное обеспечение, (Сюрприз!), Которое будет предполагать, что вся электронная почта является строчной, и по этой причине эти люди и программное обеспечение будут отправлять сообщения, используя «строчную версию» адреса независимо от того, как оно было предоставлено. им. Если получатель не может получать такие сообщения, то вскоре они заметят, что они много пропустили, и переключатся на адрес электронной почты только в нижнем регистре, или настроят свой сервер без учета регистра.

Уже поздно к этому посту, но я хочу сказать что-то немного другое ...

>> "Are email addresses case sensitive?"

Ну, «Это зависит ...» (ТМ)

Некоторые организации считают, что это хорошая идея, и их почтовые серверы обеспечивают учет регистра.

Итак, для тех сумасшедших мест: «Да, электронные письма чувствительны к регистру».

Примечание. Если в спецификации указано, что вы можете что-то сделать, это еще не значит, что это хорошая идея.

Принцип KISS предполагает, что наши системы используют электронные письма без учета регистра.

Принимая во внимание, что принцип Надежности предполагает, что мы принимаем письма с учетом регистра.

Решение:

• Храните электронные письма с учетом регистра
• Отправка электронных писем с учетом регистра
• Выполнять внутренний поиск с учетом регистра

Это будет означать, что если этот адрес электронной почты уже существует: user@x.com

... и другой пользователь приходит и хочет использовать этот адрес электронной почты: USER@x.com

... что наша логика поиска без учета регистра вернет сообщение об ошибке «Это письмо уже существует».

Теперь у вас есть решение: адекватно ли это решение в вашем случае?

В противном случае вы могли бы взимать плату за удобство для тех клиентов, которым требуется поддержка их чувствительных к регистру электронных писем, и внедрять пользовательскую логику, которая позволяет USER@x.com в вашу систему, даже если user@x.com уже существует.

В этом случае ваша логика поиска / проверки электронной почты может выглядеть примерно так: псевдокод:

if (user.paidEmailFee) {
   // case sensitive email
   query = "select * from users where email LIKE ' + user.email + '"
} else {
   // case insensitive email
   query = "select * from users where email ILIKE ' + user.email + '"
}

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

ps ILIKE - это ключевое слово PostgreSQL: http://www.postgresql.org/docs/9.2/static/functions-matching.html.

IETF Открытые Стандарты RFC 5321 2.4. Общие принципы синтаксиса и модель транзакции

Реализации SMTP ДОЛЖНЫ заботиться о сохранении локальных частей почтового ящика. В частности, для некоторых хостов пользователь «smith» отличается от пользователя «Smith».

Домены почтовых ящиков следуют обычным правилам DNS и поэтому не чувствительны к регистру

На @ l3x, это зависит.

Ясно, что есть два набора общих ситуаций, в которых правильный ответ может отличаться, наряду с третьим, который не является таким общим:

а) Вы пользователь, отправляющий личные письма :

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

б) Вы разрабатываете почтовое программное обеспечение :

См. RFC5321 2.4 отрывок внизу.

Когда вы разрабатываете почтовое программное обеспечение, вы хотите быть RFC-совместимым. Вы можете сделать адреса электронной почты своих пользователей нечувствительными к регистру, если хотите (и, вероятно, должны). Но чтобы быть RFC-совместимым, вы ДОЛЖНЫ обращаться с внешними адресами как с учетом регистра .

c) Управление списками адресов электронной почты в качестве сотрудника :

Возможно, что один и тот же получатель электронной почты добавляется в список более одного раза, но в другом случае. В этой ситуации, хотя адреса технически отличаются, это может привести к получению дубликатов электронной почты получателем. То, как вы относитесь к этой ситуации, аналогично ситуации а) в том, что вы, вероятно, можете рассматривать их как дубликаты и удалять дублирующиеся записи. Однако лучше относиться к ним как к особым случаям, отправив «напоминание» по почте на оба адреса, чтобы спросить их, являются ли они дубликатами друг друга, и, если это так, какой адрес электронной почты предпочитает использовать получатель.

С юридической точки зрения, если вы удалите дубликат без подтверждения / разрешения с обоих адресов, вы можете нести ответственность за утечку личной информации / аутентификацию на неавторизованный адрес просто потому, что два фактически отдельных получателя имеют один и тот же адрес в разных случаях .

Выдержка из RFC5321 2.4:

Локальная часть почтового ящика ДОЛЖНА БЫТЬ обрабатываться с учетом регистра. Поэтому реализации SMTP ДОЛЖНЫ позаботиться о том, чтобы сохранить случай локальных частей почтового ящика. В частности, для некоторых хостов пользователь «smith» отличается от пользователя «Smith». Однако использование чувствительности к регистру локальных частей почтового ящика затрудняет взаимодействие и не поощряется.