EmailAddressAttribute 允许在末尾添加点

Posted

技术标签:

【中文标题】EmailAddressAttribute 允许在末尾添加点【英文标题】:EmailAddressAttribute allow dot on the end 【发布时间】:2018-08-15 15:18:55 【问题描述】:

.NET 4.6.1 中的。 这意味着以下电子邮件:someone@google.com。已验证。 对于 Microsoft,此电子邮件有效。 但是,例如,对于 PayPal,电子邮件无效。

那么有人知道,电子邮件末尾的点是否有效?

【问题讨论】:

而且你不能从Gmail帐户发送带有点的电子邮件... 那里is no perfect regex for emails。但你可能会选择a better one。 谢谢大家的回答。我还发现,如果我想从 Outlook 发送末尾带有点的电子邮件,电子邮件服务器将不会发送它。但是如果我通过代码发送它,我会收到电子邮件。 :) 【参考方案1】:

关于这是否合法或有效,有很多有争议的信息。这是两种不同的观点,我将尝试解释一下原因。

RFC 5322 - Internet Message Format 部分描述了电子邮件地址,其中详细解释了电子邮件格式。

3.4.1 - Addr-spec 部分解释了电子邮件地址格式。为简洁起见,我在解释,但一般格式是:

本地部分@域

本地名称描述为以下dot-atom / quoted-string / obs-local-part 之一,域描述为dot-atom / domain-literal / obs-domain

所以它是一个域名,在RFC 1034 - Domain Names - Concepts And Facilities中有描述。

域名可以是不明确的,也可以是明确的,由是否存在尾随点来定义。不明确的域名不能保证解析到某个位置,但大多数(如果不是全部)DNS 搜索列表在不存在的情况下会在幕后附加一个句点,但这是对生活质量的改进。明确的域名必须包含一个尾随句点,它基本上是 DNS 中的终止字符。

Thomas Flinkow 已经提到了源代码的样子,我只是想提供一些背景信息,说明为什么 - 从历史上看 - 正则表达式可能是这样的。尾随句点是合法的,但有效性由邮件提供商定义。

【讨论】:

【参考方案2】:

好吧,因为我没有找到任何文档,所以我检查了source of the EmailAddressAttribute 看看是否有任何 cmets 解释了是否

someone@google.com。

被认为是有效的,但我没有找到与此相关的 cmets。

我找到的是这个正则表达式,它是用来判断一个地址是否无效的:

^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`\|~]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`\|~]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*
(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|
[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09
\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*
(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$

显然很长。然而,有趣的部分是最后的这个小部分:

\.?

表示匹配0和1之间的“。”字符

因此,我觉得有意内置了以句点结尾的电子邮件地址被认为是有效的,尽管我还没有找到任何外部资源来说明以句点结尾的电子邮件地址是否真的被允许任何电子邮件提供商。

对于验证,我建议不要只依赖 EmailAddressAttribute,而是制作自己的验证器(因为 EmailAddressAttributesealed 并且您不能派生自己的属性),这看起来有点像这个:

public bool IsValidEmailAddress(string email)

    var emailValidator = new EmailAddressAttribute();
    return emailValidator.IsValid(email) && !String.EndsWith(".");

在上面的代码中,该属性用于提供基本的检查实现,!String.EndsWith(".") 负责处理被错误地确定为有效且具有尾随句点的电子邮件地址。


TL;DR:确定的答案似乎是 Yannick Meeus 写的:

尾随句点是合法的,但有效性由邮件定义 供应商。

因此微软似乎已经遵守了这些规则,尽管实际上只有少数(没有?)邮件提供商允许使用尾随句点。因此,您必须决定是否也确认正式规则并允许尾随“。”或者如果你想排除它(如上面的示例代码所示)。

【讨论】:

在发布后的 15 分钟内,你把这一切都挖出来了吗? 我也在寻找这个属性的正则表达式,最后也看到了点。但不确定什么是正确的电子邮件地址格式。

以上是关于EmailAddressAttribute 允许在末尾添加点的主要内容,如果未能解决你的问题,请参考以下文章

EmailAddressAttribute 验证规则

EmailAddressAttribute 错误地将法国电子邮件地址分类为无效

为啥 EmailAddressAttribute.IsValid 和 MailAddress 认为包含“ª”的电子邮件是有效的? [复制]

针对无效字符验证电子邮件地址

允许在 dataGridview 中选择行,但不允许选择单元格

如何知道用户在推送通知中点击了“不允许”[重复]