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


305

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

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


Ответы:


366

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

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

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

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

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

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


81
«Короче говоря, вы можете обращаться с адресами электронной почты без учета регистра». Я бы сформулировал это сильнее: «вы небезопасно относитесь к адресам электронной почты с учетом регистра», особенно при проверке дубликатов в пользовательских базах данных и т. Д.
Geert-Jan

61
Я не согласен с выводом. Если вы ищете дубликаты в базе данных - да, сопоставление без учета регистра, вероятно, является наилучшим способом, но я видел код, в котором адрес электронной почты преобразуется в нижний регистр перед отправкой. Это не очень хорошая идея, так как есть небольшой шанс, что она не будет доставлена. То, как вы к этому относитесь, зависит от того, каковы последствия ошибки и что вы делаете с адресами электронной почты в это время (сопоставление списка уникальных адресов, отправка электронной почты и т. Д.).
Питер Баньялл

11
Кто-нибудь знает список почтовых продуктов, которые (а) отклонят запрос John.Doe@company.com, когда пользователь john.doe@company.com действителен, или (б) разрешат создание двух отдельных почтовых ящиков: Джон .Doe @ company.com и john.doe@company.com?
MSC

51
Я работаю в большой компании, и есть еще один человек с таким же именем и фамилией. Сегодня я обнаружил, что его локальная часть отличается от моей только заглавными буквами. Это работало должным образом, поэтому я был удивлен, увидев, что «ни одна из широко используемых почтовых систем не различает разные адреса в зависимости от регистра». Мы используем MS Exchange, который я бы назвал «широко используемым».
Мэтью Джеймс Бриггс

7
RFC 5321 2.4. Общие принципы синтаксиса и модель транзакций - реализации SMTP ДОЛЖНЫ заботиться о сохранении локальных частей почтового ящика. В частности, для некоторых хостов пользователь «smith» отличается от пользователя «Smith». Домены почтовых ящиков следуют обычным правилам DNS и, следовательно, не чувствительны к регистру.
Adam111p

43

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

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


14
Это проницательное применение закона Постеля en.wikipedia.org/wiki/Robustness_principle . По-прежнему неправильно писать программное обеспечение, которое предполагает, что локальные части адресов электронной почты нечувствительны к регистру, но да, учитывая, что существует множество неправильного программного обеспечения, также недостаточно надежно требовать учета регистра, если вы принимаете почту. ,
зигг

1
Одна из вещей, которые меня больше всего расстраивают, это сайты, заставляющие меня писать свои письма в нижнем регистре. Просто отправил гневный комментарий Twitch.tv по поводу того, что касается их сайта поддержки. Они запрещают вам даже вводить заглавные буквы на своем сайте. Поэтому, хотя я знаю, что мой почтовый сервер рассматривает их как нечувствительные к регистру, и я знаю, что RFC утверждает, что он чувствителен к регистру, сайты НИКОГДА не должны делать какие-либо предположения в любом случае и должны просто проходить через то, что вводит пользователь. ЧЕЛОВЕК, что так раздражает !!!
Марк А. Донохо

Лично, когда я набираю свою электронную почту где-то, я предпочитаю использовать смешанный регистр, чтобы он был более читабельным. Например: JamesTKirk@domain.com (не мой реальный адрес). Я делаю это, хотя получаю письмо без прописных букв.
PaulOTron2000

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

31

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

>> "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.


8
LIKE / ILIKE для точного соответствия - ужасная идея. Представьте себе электронное письмо, содержащее %или, что более вероятно,_
ThiefMaster

18
Ваши очки великолепны! Но инъекция sql в вашем примере как бы рушит это :(
epelc 19.09.16

6
@epelc ЭТО. Не может согласиться. Такой тип построения запросов нигде не должен быть написан, даже если это всего лишь пример.
xDaizu

1
@ l3x, хотя я не так сильно против приведенного выше примера кода, как другие, особенно потому, что вы назвали его псевдокодом, и это только для иллюстрации, возможно, все вышеприведенные комментарии можно решить, заменив ваши query = ...строки на простые query = // Insert case-sensitive/insensitive search hereкомментарии, поскольку это удерживает разговор от темы внедрения SQL и фокусируется на том, что вы пытаетесь показать. Другими словами, придерживайтесь логики, а не реализации. Это заставит замолчать критиков.
Марк А. Донохо

10

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

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

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


3

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

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

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

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

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

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

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

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

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

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

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

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

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