来自RFC 5321，章节2.3.11:

标准邮箱命名约定定义为 “local-part@domain”;当代的用法允许更广泛的 应用程序而不是简单的“用户名”。因此，由于 当中间主机尝试时出现长期的问题 通过修改它们来优化传输，局部部分必须是 类中指定的主机只能解释和分配语义 地址的域部分。

因此，“@”之前的部分可以区分大小写，因为它完全在主机系统的控制之下。但实际上，没有广泛使用的邮件系统根据大小写来区分不同的地址。

@符号后面的部分是域名，根据RFC 1035第3.1节，

名称服务器和解析器必须以不区分大小写的方式比较[域]

简而言之，电子邮件地址不区分大小写是安全的。

写这篇文章已经晚了，但我有一些稍微不同的东西要说……

>> "Are email addresses case sensitive?"

嗯，“看情况……”(TM)

一些组织实际上认为这是一个好主意，他们的电子邮件服务器强制区分大小写。

所以，对于那些疯狂的地方，“是的，电子邮件是区分大小写的。”

注意:仅仅因为一个规范说你可以做一些事情，并不意味着这样做是一个好主意。

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 ?"
} else {
   // case insensitive email
   query = "select * from users where email ILIKE ?"
}
 

这样，你主要是在强制不区分大小写，但如果客户使用的电子邮件系统支持这种毫无意义的支持，则允许客户为这种支持付费。

p.s. ILIKE是一个PostgreSQL关键字:http://www.postgresql.org/docs/9.2/static/functions-matching.html

来自RFC 5321，章节2.3.11:

标准邮箱命名约定定义为 “local-part@domain”;当代的用法允许更广泛的 应用程序而不是简单的“用户名”。因此，由于 当中间主机尝试时出现长期的问题 通过修改它们来优化传输，局部部分必须是 类中指定的主机只能解释和分配语义 地址的域部分。

因此，“@”之前的部分可以区分大小写，因为它完全在主机系统的控制之下。但实际上，没有广泛使用的邮件系统根据大小写来区分不同的地址。

@符号后面的部分是域名，根据RFC 1035第3.1节，

名称服务器和解析器必须以不区分大小写的方式比较[域]

简而言之，电子邮件地址不区分大小写是安全的。

对于@l3x，这取决于。

显然有两种情况下正确答案可能不同，还有第三种情况不那么普遍:

a)您是发送私人邮件的用户:

很少有现代电子邮件系统实现区分大小写，所以你可以忽略大小写，选择任何你想使用的大小写。这并不能保证你所有的邮件都会被送达，但是很少有邮件会受到负面影响，所以你不必担心。

b)您正在开发邮件软件:

见RFC5321 2.4节选在底部。

在开发邮件软件时，您希望与rfc兼容。如果你想的话，你可以让你自己的用户的电子邮件地址不区分大小写(你可能应该这样做)。但是为了与RFC兼容，你必须将外部地址区分大小写。

c)作为员工管理公司拥有的电子邮件地址列表:

It is possible that the same email recipient is added to a list more than once - but using different case. In this situation though the addresses are technically different, it might result in a recipient receiving duplicate emails. How you treat this situation is similar to situation a) in that you are probably fine to treat them as duplicates and to remove a duplicate entry. It is better to treat these as special cases however, by sending a "reminder" mail to both addresses to ask them if the case of the email address is accurate.

从法律角度来看，如果你在没有确认/许可的情况下从两个地址删除副本，你可能要为泄露私人信息/身份验证到未经授权的地址而负责，因为两个实际上独立的收件人拥有相同的地址，但情况不同。

摘自RFC5321 2.4:

邮箱的本地部分必须区分大小写。 因此，SMTP实现必须注意保留大小写 邮箱本地零件。特别是，对于某些主机，用户“smith” 与用户“Smith”不同。然而，利用案例 邮箱本地部件的敏感性阻碍了互操作性 气馁。

我知道这是一个老问题，但我只是想在这里评论:在任何程度上，电子邮件地址是区分大小写的，大多数用户积极使用一个需要大写字母的电子邮件地址是“非常不明智的”。他们很快就会停止使用这个地址，因为他们会丢失很多邮件。(除非他们有特定的理由让事情变得复杂，而且他们只希望从他们认识的特定发件人那里收到邮件。)

这是因为不完美的人和不完美的软件都存在，(惊讶!)它会假设所有的电子邮件都是小写的，因此这些人和软件将使用“小写版本”的地址发送消息，而不管它是如何提供给他们的。如果收件人无法收到这样的邮件，他们很快就会发现自己丢失了很多信息，并切换到只使用小写字母的电子邮件地址，或者将服务器设置为不区分大小写。

IETF开放标准RFC 5321通用语法原则和事务模型

SMTP实现必须注意保留邮箱的大小写 本地零件。特别是，对于某些主机，用户“smith”为 不同于用户“史密斯”。

邮箱域遵循正常的DNS规则，因此不是case 敏感的