你会收到其他 Sean Conners 的邮件,这可能要部分归咎于 Gmail。
Gmail might partially be to blame for receiving emails from other Sean Conners

原始链接: https://boston.conman.org/2026/08/11.1

作者探讨了因与他人重名而持续收到发给对方的电子邮件所带来的困扰。这一常见问题源于 Gmail 忽略用户名中句点的政策。尽管谷歌坚称“firstname.lastname”和“firstnamelastname”是同一个地址,不可能由不同用户持有,但作者援引的轶事证据和 Stack Exchange 上的讨论表明,该系统偶尔会出错,导致不同用户之间发生真实的隐私泄露。 文章强调了谷歌在处理本地部分地址时,其依赖协议规范的“标准答案”与长期用户反馈的经验现实之间存在脱节。作者指出,正是由于这些系统性错误以及谷歌拒绝承认其程序可能存在缺陷,他已不再使用 Gmail 进行敏感或机密的沟通。文章最后简要探讨了电子邮件地址中允许使用的字符,并强调许多用户至今仍难以理解其电子邮件账户的基本运行机制。

Hacker News 社区近期针对“Gmail 是否会将发送给其他人的邮件错误地投递到无关账户”这一问题进行了讨论,焦点主要在于电子邮件地址中圆点(.)的使用。 长期使用 Gmail 的用户以及熟悉谷歌架构的人士普遍认为,**不存在这样的系统漏洞**。自 Gmail 诞生以来,该服务在处理地址时便忽略圆点的位置(例如,`[email protected]` 与 `[email protected]` 被视为同一个地址)。谷歌不允许两个不同的用户注册仅圆点位置不同的账号;默认情况下,用户拥有自己账号的所有圆点排列组合形式。 大多数参与讨论者认为,收到“他人的邮件”是人为错误所致。用户经常会忘记自己的邮箱地址、输入错误,或遗漏了地址中的中间名首字母、数字等区分字符。虽然收到本应发给同名者的敏感信息会令人感到困扰,但这通常被认为是用户自身混淆或疏忽的结果,而非谷歌的技术故障或安全漏洞。
相关文章

原文

Gmail might partially be to blame for me receiving emails from other Sean Conners

I was reading the Lobsters thread about the article “A researcher bought noreply.net. Companies started sending him secrets” when I left a comment about my own struggles with receiving emails for other Sean Conners. That started a thread that swamped the comment section about other people who had similar stories, so it's nice to know that I'm not alone. Also, here's one of my favorite comments in that thread (for reasons that should be apparent):

I was about to say, "I know a guy with a whole blog series about that." But then I looked, and you were him.

Lobsters comment from Jason McBrayer

Heh.

But the thread as a whole left me with the idea that there's still a lot of people out there that barely understand email and aren't even sure what their own email even is. Sad.

I did get an email about my comment from Keong Lim, claiming it was mostly Google's fault for the confusion and linked to this fairly damning answer at Stack Exchange:

It is a lesson in human nature that so many experts simply recite Google's pat answer on this as if an assertion were identical to empirical reality. I am one of the early account holders with the [email protected] accounts. About three years ago, I began receiving email directed to [email protected]. By triangulating the information I was able to glean from their dry cleaners, car dealer, etc. I was finally able to contact these people (about 3,000 miles from me, BTW). The DO have the same account as me, minus the period. We were able to determine that only a portion of email "leaks" across accounts. Unfortunately, the fact that I had my account 10 years before they had theirs did not convince them to leave the account to me. Thus, I live with the occasional notice from the bank, school, etc. Because of this, I no longer use Gmail for anything important or confidential.

The most disturbing thing to me is Google's insistence that they could not have made a programming mistake when they clearly did. These folks are arrogant in their faux humility.

Why does Google not consider dot in usernames of Gmail addresses?

The “pat answer” is that Google is that it's cutting down on possible confusion over who receives firstname.lastname@gmail.com and firstnamelastname@gmail.com, but it seems that the “pat answer” is a somewhat later change to Gmail to ignore periods in the local part (the part before the “@”) of the email address. I think Gmail is leaning heavily upon this portion of “RFC-5321: Simple Mail Transfer Protocol” to justify this:

2.3.11. Mailbox and Address

As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited. … Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.

(emphasis added)

I know I signed up early enough to Gmail to get [email protected] and at that time, [email protected] might have been considered a different email address. After the change, it appears that Gmail might get confused sometimes and mess up some legacy addresses at times.

While reading all that, I did go down a small rabbit hole with what characters are actually allowed in an email address. It's unclear if anything but ASCII is allowed, but there are surprisingly little in ASCII that isn't allowed. Out of the 95 defined graphic characacters (which I'm including the space character), the following are not allowed:

ASCII characters not allowed in an email address
character name
  Space
" Quotation Mark
( Left Parenthesis
) Right Parenthesis
, Comma
: Colon
; Semicolon
< Less-than Sign
> Greater-than sign
@ Commercial At
[ Left Square Bracket
\ Reversed Solidus
] Right Square Bracket

Technically, they could be used in an email address if they're escaped, but it's discouraged heavily.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

联系我们 contact @ memedata.com