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

Sta*_*ker 274 email smtp rfc

我读过,通过电子邮件标准的第一部分是区分大小写的,但是我试着将电子邮件发送到name@example.com,Name@example.comNAME@example.com-它在每种情况下已经到来.

邮件服务器如何处理用户名?是否有可能错过案例并且不会传递该消息?使用与提供电子邮件地址时注册时所写的完全相同的字母大小写真的非常重要吗?

Mik*_*e E 329

从RFC 5321,第2.3.11节:

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

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

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

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

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

  • "简而言之,您可以安全地将电子邮件地址视为不区分大小写." 我强调它更强:"将电子邮件地址视为区分大小写的方式是不安全的"特别是在检查用户数据库中的重复项等时. (74认同)
  • 我不同意这个结论.如果您正在寻找数据库中的重复项 - 是的,不区分大小写的匹配可能是最好的方法,但我已经看到了在发送之前将电子邮件地址转换为小写的代码.这不是一个好主意,因为它很有可能无法交付.所以你如何对待它取决于错误的后果是什么以及你当时对电子邮件地址做了什么(整理一个唯一地址列表,发送电子邮件等). (55认同)
  • 我在一家大公司工作,还有另一个人姓名相同.我今天发现他的本地部分与我的不同仅在资本化方面.这一直在正常工作,所以我很惊讶地看到"没有广泛使用的邮件系统根据案例区分不同的地址".我们使用MS Exchange,我称之为"广泛使用". (43认同)
  • 有没有人知道邮件产品列表,它们将(a)在用户john.doe@company.com有效时拒绝John.Doe@company.com,或者(b)允许创建两个不同的邮箱:John .Doe @ company.com和john.doe@company.com? (10认同)
  • 您的答案是字面意思:是的,电子邮件地址(作为一个整体)区分大小写。因此,将它们视为不区分大小写。 (5认同)
  • RFC 5321 2.4.一般语法原则和事务模型 - SMTP实现必须注意保留邮箱本地部分的大小写.特别是,对于某些主机,用户"smith"与用户"Smith"不同.邮箱域遵循正常的DNS规则,因此不区分大小写. (4认同)
  • 你的结论直接与所提供的来源相矛盾 (4认同)
  • 虐待怎么样?有长电子邮件地址的人可以注册并验证n个帐户. (2认同)
  • @theminhai 拥有 Gmail 帐户的人已经可以以“用户名+anythingyouwant@gmail.com”的形式注册 ∞ 个帐户。 (2认同)
  • 您的结论是错误的,正如您在 RFC 1035 中所说,某些邮件服务器区分大小写,而其他邮件服务器则不区分大小写。最好确保电子邮件的大小写正确,因为在某些服务器上 matthew@stidmatt.com、Matthew@stidmatt.com、MaTthEw@stidmatt.com 是不同的,您并不总是知道答案,我的我和同事刚刚发现,如果电子邮件是垃圾邮件,他们不会向您发送自动回复。TLDR:最好对所有地址使用小写字母。 (2认同)

Pau*_*000 41

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

这是因为不完美的人类以及不完美的软件存在,(惊喜!)将假设所有电子邮件都是小写的,因此这些人和软件将使用地址的"低级版本"发送消息,而不管它是如何提供的给他们.如果收件人无法收到此类邮件,则不久之后他们会发现自己丢失了很多邮件,并切换到仅限小写的电子邮件地址,或者将其服务器设置为不区分大小写.

  • 这是Postel法律的深刻见解http://en.wikipedia.org/wiki/Robustness_principle.编写假定电子邮件地址的本地部分不区分大小写的软件仍然是错误的,但是,鉴于存在大量错误的软件,如果您是接受邮件的人,则要求区分大小写也不够强大. . (14认同)
  • 我最沮丧的事情之一是网站*强迫*我用全小写写电子邮件。刚刚向 Twitch.tv 就其支持网站的此事发表了愤怒的评论。他们甚至阻止您在他们的网站上“输入”大写字母。因此,虽然我知道我的电子邮件服务器将它们视为不区分大小写,并且我知道 RFC 声明它区分大小写,但网站永远不应该以任何方式做出任何假设,而应该简单地传递用户输入的内容。男人真是太烦人了!!! (4认同)
  • 不过,作为软件作者,您希望您的服务成为为数不多的能够通过区分大小写的电子邮件为该人提供正确服务的服务之一。 (3认同)
  • 就我个人而言,当我在某个地方输入电子邮件时,我更喜欢使用混合大小写,这样更清晰。例如:JamesTKirk@domain.com(不是我的真实地址。)即使我收到的电子邮件没有大写字母,我也会这样做。 (2认同)

l3x*_*l3x 27

这个帖子来得太晚了,但我说的有点不同......

>> "Are email addresses case sensitive?"
Run Code Online (Sandbox Code Playgroud)

嗯,"它取决于......"(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 + '"
}
Run Code Online (Sandbox Code Playgroud)

这样,您通常会强制执行不区分大小写,但如果客户使用支持此类废话的电子邮件系统,则允许客户支付此类支持.

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

  • 你的观点很棒!但是在你的例子中的sql注入它的废墟:( (12认同)
  • LIKE/ILIKE完全匹配是一个糟糕的主意.想象一下包含`%`或更多可能`_`的电子邮件 (7认同)
  • @epelc这个.不能同意更多.这种查询构建不应该写在任何地方,即使它只是一个例子. (4认同)
  • @l3x,虽然我不像其他人那样强烈反对上面的示例代码,特别是因为您确实将其称为伪代码并且它仅用于说明目的,也许上述所有评论都可以通过替换您的“查询”来解决= ...` 行带有简单的 `query = // Insert case-sensitive/insensitive search here` 注释,这样可以使对话远离 SQL 注入主题并专注于您想要显示的内容。换句话说,保持逻辑,而不是实现。这会让批评者闭嘴。 (3认同)
  • 我反对使用“电子邮件”一词来表示电子邮件地址。 (2认同)

Ada*_*11p 9

RFC 5321 2.4.一般语法原则和交易模型

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

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


zaT*_*cky 6

每个@l3x,这取决于。

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

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

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

b)您正在开发邮件软件

请参阅底部的 RFC5321 2.4 摘录。

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

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

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

从法律的角度来看,如果您在没有确认/许可的情况下从两个地址中删除重复项,您可能需要为将私人信息/身份验证泄露到未经授权的地址负责,因为两个实际分开的收件人不同的情况下具有相同的地址

摘自 RFC5321 2.4:

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

  • 为了完整起见,也来自 RFC5321,但第 4.1.2 节:“虽然本地部分的上述定义相对宽松,但为了最大程度地实现互操作性,期望接收邮件的主机应该避免在本地部分需要(或使用) 引用字符串形式或本地部分区分大小写。对于任何需要生成或比较本地部分(例如,与特定邮箱名称)的目的,所有引用的表格必须被视为等效,并且发送系统应该传输使用尽可能少的引用的表格。 (4认同)