30 lines
2.3 KiB
Markdown
30 lines
2.3 KiB
Markdown
|
+++
|
||
|
|
title = "case sensitivity in email addresses"
|
||
|
|
+++
|
||
|
|
|
||
|
|
domain names are case-insensitive, but the local part of an email MAY be case sensitive, though it SHOULD NOT be case sensitive.
|
||
|
|
|
||
|
|
https://www.reddit.com/r/todayilearned/comments/2r264r/comment/cnbuk7w/
|
||
|
|
|
||
|
|
> Way back when Compuserve and AOL were top-tier ISPs, maybe. Each of the RFCs supercedes the old ones. Even your source acknowledges this isn't the practice:
|
||
|
|
>
|
||
|
|
>> Interpretation of the local-part of an email address is dependent on the conventions and policies implemented in the mail server. For example, case sensitivity may distinguish mailboxes differing only in capitalization of characters of the local-part, although this is not very common.[6]
|
||
|
|
>
|
||
|
|
> Your source also goes on to talk about updates, like Google making their own additions with the extra dots and plus sign.
|
||
|
|
>> Gmail ignores all dots in the local-part for the purposes of determining account identity.[7] This prevents the creation of user accounts your.user.name or yourusername when the account your.username already exists.
|
||
|
|
>
|
||
|
|
> This may be misleading because the information about the email protocols has been updated, and the old protocols are no longer valid.
|
||
|
|
> - RFC 821 was the original (1982) email protocol, sure +case sensitive.
|
||
|
|
> - RFC 2821 (2001) makes 821 & others obsolete - still +case-sensitive.
|
||
|
|
> - RFC 5321 (2008) RFC 2821 is obsolete - perhaps, but no longer considered common
|
||
|
|
>
|
||
|
|
>> Mailbox = Local-part "@" ( Domain / address-literal )
|
||
|
|
>>
|
||
|
|
>> Local-part = Dot-string / Quoted-string ; MAY be case-sensitive
|
||
|
|
>
|
||
|
|
> RFC 6530 (2012)- acknowledges this is a bad idea.
|
||
|
|
>> 10.1. Choices of Mailbox Names and Unicode Normalization
|
||
|
|
>>
|
||
|
|
>> It has long been the case that the email syntax permits choices about mailbox names that are unwise in practice, if one actually intends the mailboxes to be accessible to a broad range of senders. The most often cited examples involve the use of case-sensitivity and tricky quoting of embedded characters in mailbox local parts. These deliberately unusual constructions are permitted by the protocols, and servers are expected to support them. Although they can provide value in special cases, taking advantage of them is almost always bad practice unless the intent is to create some form of security by obscurity
|
||
|
|
>
|
||
|
|
> e-mail addresses WERE supposed to be case sensitive, but it was always a bad idea
|