电子邮件地址区分大小写吗?


304

我已经读过,按照标准,电子邮件的第一部分区分大小写,但是我尝试将电子邮件发送到name@example.comName@example.com并且NAME@example.com-在每种情况下都已经到达。

邮件服务器如何处理用户名?是否有可能错过案件而该消息将不会发送?使用完全相同的字母大小写,就像在注册时提供电子邮件地址时写的那样,真的非常重要吗?


Answers:


365

根据RFC 5321第2.3.11节

标准邮箱命名约定定义为“ local-part @ domain”。与简单的“用户名”相比,现代用法允许更广泛的应用程序集。因此,由于长期存在的问题历史,当中间主机试图通过修改它们来优化传输时,本地部分务必只能由地址的域部分中指定的主机来解释和分配语义。

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

但是,@符号后的部分是域,根据RFC 1035第3.1节,

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

简而言之,您可以安全地将电子邮件地址视为不区分大小写。


81
简而言之,您可以安全地将电子邮件地址区分大小写。我要说的更强:“您不安全地将电子邮件地址视为区分大小写的方式”(尤其是在检查用户数据库中的重复项等时)
Geert-Jan 2013年

61
我不同意这个结论。如果要在数据库中查找重复项-是的,不区分大小写的匹配可能是最好的选择,但是我已经看到了在发送之前将电子邮件地址转换为小写字母的代码。这不是一个好主意,因为极有可能无法交付。因此,您如何处理它取决于错误的后果以及当时您对电子邮件地址的处理方式(整理唯一地址列表,发送电子邮件等)。
Peter Bagnall 2014年

10
是否有人知道将在用户john.doe@company.com有效时拒绝(a)拒绝John.Doe@company.com的邮件产品列表,或(b)允许创建两个不同的邮箱: .doe @ company.com和john.doe@company.com?
MSC

51
我在一家大公司工作,还有另一个人的名字和姓氏相同。今天,我发现他的本地人仅在大小写方面与我的不同。这一直工作正常,所以我很惊讶地看到“没有广泛使用的邮件系统根据大小写区分不同的地址”。我们使用MS Exchange,我将其称为“广泛使用”。
马修·詹姆斯·布里格斯

7
RFC 5321 2.4。通用语法原则和事务模型-SMTP实现必须注意保留邮箱本地部分的大小写。特别是,对于某些主机,用户“史密斯”不同于用户“史密斯”。邮箱域遵循正常的DNS规则,因此不区分大小写。
亚当111p

43

我知道这是一个老问题,但是我只想在这里发表评论:无论如何,电子邮件地址都区分大小写,大多数用户“非常不明智”地主动使用需要大写字母的电子邮件地址。他们很快就会停止使用该地址,因为他们会丢失很多邮件。(除非他们有使事情变得困难的特定原因,并且他们只希望收到他们认识的特定发件人的邮件。)

那是因为存在不完善的人以及不完善的软件((惊喜!),它将假定所有电子邮件都是小写的,因此,这些人和软件将使用地址的“小写版本”发送邮件,而不管其提供方式如何给他们。如果收件人无法接收到此类消息,则很快就会发现收件人丢失了很多消息,并切换到仅使用小写字母的电子邮件地址,或者将服务器设置为不区分大小写。


14
这是Postel法则en.wikipedia.org/wiki/Robustness_principle的有见地的应用。编写假定电子邮件地址本地部分不区分大小写的软件仍然是错误的,但是是的,鉴于那里有很多错误的软件,如果您是接受邮件的人,则要求区分大小写也不够可靠。
Zigg 2012年

1
我最沮丧的事情之一是网站强迫我以小写形式写电子邮件。刚刚向Twitch.tv发出了关于其支持网站的愤怒评论。他们甚至阻止您在自己的网站上输入大写字母。因此,尽管我知道我的电子邮件服务器将它们视为不区分大小写,并且我知道RFC声明它是区分大小写的,但网站绝不应该以任何方式做出任何假设,而应该简单地通过用户输入的内容。真是令人讨厌的人!!!
Mark A. Donohoe

就个人而言,当我在某处键入电子邮件时,我更喜欢使用大小写混合的形式,这样更易​​读。例如:JamesTKirk@domain.com(不是我的真实地址。)即使我收到的电子邮件中没有大写字母,我仍然会这样做。
PaulOTron2000

31

这篇文章太晚了,但是我有一点话要说...

>> "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 ' + 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 '16

16
您的观点很棒!但是您示例中的sql注入破坏了它:(
epelc

6
@epelc这。不能完全同意。即使只是示例,也不应该在任何地方编写这种查询构建。
xDaizu

1
@ l3x,尽管我并不像其他例子那样强烈反对上面的示例代码,特别是因为您确实将其称为伪代码,并且仅出于说明目的,也许可以通过将您的query = ...行替换为来解决以上所有注释。简单的query = // Insert case-sensitive/insensitive search here注释,使对话远​​离SQL注入主题,并专注于您要显示的内容。换句话说,保持逻辑,而不是实现。它将使批评者保持沉默。
Mark A. Donohoe

9

RFC 5321 2.4。通用语法原则和交易模型

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

邮箱域遵循正常的DNS规则,因此不区分大小写


3

每@ l3x,这取决于。

显然,在两种常见情况下,正确答案可能有所不同,而在第三种情况下,答案并不那么普遍:

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

很少有现代化的电子邮件系统实施情况的敏感性,所以你可能罚款,忽略大小写,并选择您觉得什么样的情况下使用。无法保证您的所有邮件都会被递送-但是很少有邮件会受到负面影响,您不必担心。

b)您正在开发邮件软件

请参阅底部的RFC5321 2.4摘录。

在开发邮件软件时,您希望符合RFC。你可以让自己的用户的电子邮件地址不区分大小写的,如果你想(和你应该)。但是为了符合RFC,您必须将外部地址视为区分大小写

c)以员工身份管理企业拥有的电子邮件地址列表

同一电子邮件收件人有可能多次添加到列表中,但使用了不同的大小写。在这种情况下,尽管地址在技术上有所不同,但可能导致收件人收到重复的电子邮件。您如何看待这种情况是在你类似情况)可能是罚款,将它们视为重复和删除重复项。最好将这些邮件视为特殊情况,方法是将“提醒”邮件发送到两个地址,询问它们是否重复,如果重复,则询问收件人希望使用哪个电子邮件地址。

从法律的角度来看,如果您从两个地址中删除未经确认/允许的重复副本,您可能要负责私人信息/身份验证泄露给未经授权的地址,这仅仅是因为两个实际分开的收件人不同的情况下拥有相同的地址

摘自RFC5321 2.4:

邮箱的本地部分必须视为区分大小写。因此,SMTP实现必须注意保留邮箱本地部分的大小写。特别是,对于某些主机,用户“史密斯”不同于用户“史密斯”。但是,利用邮箱本地部分的区分大小写会阻碍互操作性,因此不建议使用。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.