ChatGPT解决这个技术问题 Extra ChatGPT

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

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

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


C
Community

RFC 5321, section 2.3.11

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

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

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

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

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


“简而言之,您可以安全地将电子邮件地址视为不区分大小写。”我会说得更强烈:“将电子邮件地址视为区分大小写的方式是不安全的”,尤其是在检查用户数据库等中的重复项时。
我不同意这个结论。如果您要在数据库中查找重复项 - 是的,不区分大小写的匹配可能是最好的方法,但我已经看到在发送之前将电子邮件地址转换为小写的代码。这不是一个好主意,因为它无法交付的可能性很小。因此,您如何处理它取决于错误的后果是什么以及您当时对电子邮件地址所做的事情(整理唯一地址列表、发送电子邮件等)。
有谁知道一个邮件产品列表(a)当用户 john.doe@company.com 有效时拒绝 John.Doe@company.com,或者(b)将允许创建两个不同的邮箱:John .Doe@company.com 和 john.doe@company.com?
我在一家大公司工作,还有另一个人的名字和姓氏相同。我今天发现他的 local-part 与我的仅在大写上有所不同。这一直在正常工作,所以我很惊讶地看到“没有广泛使用的邮件系统根据大小写区分不同的地址”。我们使用我称之为“广泛使用”的 MS Exchange。
RFC 5321 2.4。一般语法原则和事务模型 - SMTP 实现必须注意保留邮箱本地部分的大小写。特别是,对于某些主机,用户“smith”与用户“Smith”不同。邮箱域遵循正常的 DNS 规则,因此不区分大小写。
P
PaulOTron2000

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

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


这是对 Postel 定律 en.wikipedia.org/wiki/Robustness_principle 的深刻应用。编写假定电子邮件地址的本地部分不区分大小写的软件仍然是错误的,但是是的,鉴于那里有很多错误的软件,如果您是接受邮件的人,那么要求区分大小写也不太可靠.
我最沮丧的一件事是网站强迫我用全小写字母写电子邮件。刚刚向 Twitch.tv 发出了关于他们支持网站的愤怒评论。他们甚至阻止您在他们的网站上输入大写字母。因此,虽然我知道我的电子邮件服务器将它们视为不区分大小写,并且我知道 RFC 声明它是区分大小写的,但网站不应该做出任何假设,而应该简单地传递用户输入的内容。男人好烦!!!
就个人而言,当我在某处输入电子邮件时,我更喜欢使用混合大小写,这样更易读。例如:JamesTKirk@domain.com(不是我的真实地址。)即使我收到的电子邮件没有大写字母,我也会这样做。
但是,作为一名软件作者,您希望您的服务成为少数几个使用区分大小写的电子邮件为这个人做正确事情的服务之一。
在 Thunderbird 上,当我输入电子邮件地址时,它会自动将其转换为小写
T
Tom

这篇文章迟到了,但我有一些稍微不同的东西要说......

>> "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 ?"
}
 

这样,您主要是强制不区分大小写,但如果客户使用支持此类废话的电子邮件系统,则允许客户为此支持付费。

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


精确匹配的 LIKE/ILIKE 是一个糟糕的主意。想象一封包含 % 或更可能是 _ 的电子邮件
你的积分太棒了!但是你的例子中的sql注入有点毁了它:(
@epelc 这个。不能同意更多。即使只是一个示例,也不应该在任何地方编写这种查询构建。
@l3x,虽然我不像其他人那样强烈反对上述示例代码,特别是因为您确实将其称为伪代码并且仅用于说明目的,也许上述所有评论都可以通过替换您的 {1 } 行带有简单的 query = // Insert case-sensitive/insensitive search here 注释,因为这样可以使对话远离 SQL 注入主题,并专注于您要展示的内容。换句话说,把它放在逻辑上,而不是实现上。它会让批评者沉默。
我反对将“电子邮件”一词用于电子邮件地址。
C
Community

IETF 开放标准 RFC 5321 2.4. General Syntax Principles and Transaction Model

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

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


z
zaTricky

根据@l3x,这取决于。

显然有两组一般情况,其中正确答案可能不同,还有第三组不那么普遍:

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

很少有现代电子邮件系统实现区分大小写,因此您可能可以忽略大小写并选择您喜欢使用的任何大小写。无法保证您的所有邮件都会送达 - 但很少有邮件会受到负面影响,因此您不必担心。

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

请参阅底部的 RFC5321 2.4 摘录。

在开发邮件软件时,您希望符合 RFC。如果您愿意(并且您可能应该这样做),您可以使您自己用户的电子邮件地址不区分大小写。但为了符合 RFC,您必须将外部地址视为区分大小写。

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

同一电子邮件收件人可能会多次添加到列表中 - 但使用不同的大小写。在这种情况下,虽然地址在技术上有所不同,但可能会导致收件人收到重复的电子邮件。您如何处理这种情况与情况 a) 类似,因为您可能可以将它们视为重复项并删除重复项。但是,最好将这些视为特殊情况,向两个地址发送“提醒”邮件,询问他们电子邮件地址的大小写是否准确。

从法律的角度来看,如果您在没有确认/许可的情况下从两个地址中删除了副本,您可能会因为两个实际分开的收件人在不同情况下具有相同的地址而将私人信息/身份验证泄漏到未经授权的地址而承担责任。

摘自 RFC5321 2.4:

邮箱的本地部分必须被视为区分大小写。因此,SMTP 实现必须注意保留邮箱本地部分的大小写。特别是,对于某些主机,用户“smith”与用户“Smith”不同。但是,利用邮箱本地部分的大小写敏感性会阻碍互操作性,因此不鼓励使用。