2026 年 8 月 11 日，Gmail 可能部分是我收到其他 Sean Conners 邮件的原因。我正在阅读 Lobsters 线程，讨论文章 "一位研究人员购买了 noreply.net。公司开始向他发送秘密" 时，我发表了一条关于自己在收到其他 Sean Conners 邮件时遇到的困难的评论。这引发了一个讨论线程，淹没了评论区，许多人分享了类似的故事，所以知道我并不孤单真是太好了。此外，这是我最喜欢的评论之一（原因应该很明显）：我本来想说，“我知道有一个人有一整套博客系列讨论这个。”但是我一查看，发现你就是他。Lobsters 评论来自 Jason McBrayer。呵呵。不过整个讨论线程给我的想法是，仍然有很多人对电子邮件几乎不理解，甚至不确定自己的电子邮件是什么。可悲。我确实收到了来自 Keong Lim 的一封关于我评论的电子邮件，声称这种困惑大部分是谷歌的错，并链接到了 Stack Exchange 上一个相当有力的回答：人类本性的一个教训是，许多专家只是简单地背诵谷歌对此的标准回答，仿佛一个断言与经验证的现实是相同的。我是 firstname.lastname@gmail.com 账户的早期持有者。大约三年前，我开始收到发往 firstnamelastname@gmail.com 的电子邮件。通过综合我从他们的干洗店、汽车经销商等得到的信息，最终我能够联系到这些人（顺便说一下，距离我大约 3000 英里）。他们与我拥有相同的账户，只是没有句点。我们能确定只有一部分电子邮件在账户之间 "泄露"。不幸的是，我在他们拥有账户的 10 年之前就拥有了我的账户，但这并没有说服他们把账户留给我。因此，我不得不忍受偶尔来自银行、学校等的通知。因此，我现在不再将 Gmail 用于任何重要或机密的事务。对我来说，最令人不安的是谷歌坚持认为他们不可能犯程序错误，尽管他们显然犯了。那些人对他们的伪谦虚表现得很傲慢。为什么谷歌不考虑 Gmail 地址用户名中的点？“标准答案”是谷歌这么做是为了减少关于谁收到 firstname.lastname@gmail.com 和 firstnamelastname@gmail.com 信息的潜在混淆，但看起来“标准答案”是 Gmail 稍晚对本地部分（“@” 之前的部分）无视句点的一种更改。我认为 Gmail 很大程度上依赖于 “RFC-5321: 简单邮件传输协议” 的这一部分来证明这一点：2.3.11. 邮箱和地址 在本规范中，"地址" 是识别用户以便投递邮件或将邮件存放的位置的字符字符串……因此，由于在尝试通过修改它们来优化传输时中间主机的长久问题，本地部分只能通过域名部分指定的主机进行解释和分配语义。（强调添加）我知道我注册 Gmail 的时候早得足够，可以得到 sean.conner@gmail.com，当时，seanconner@gmail.com 可能被视为不同的电子邮件地址。变更后，似乎 Gmail 有时会感到困惑并弄乱一些旧的地址。在阅读这些内容时，我确实陷入了一个关于电子邮件地址中实际允许哪些字符的小兔子洞。尚不清楚是否仅允许 ASCII，但在 ASCII 中出乎意料地不允许的内容不多。在 95 个定义的图形字符（我包含了空格字符）中，以下字符是不允许的：电子邮件地址中不允许的 ASCII 字符名称：空格 " 引号（左括号）右括号，逗号：冒号；分号 < 小于号 > 大于号 @ 商业符号 [ 左方括号 \ 反斜杠 ] 右方括号。从技术上讲，如果被转义，它们可以在电子邮件地址中使用，但这强烈不被提倡。您可以自由链接到这里的任何条目。我不会咬人。可以放心。我保证。日期是当天条目的永久链接（或条目，如果只有一个条目）。标题是那个条目的永久链接。链接的格式很简单：以这个网站的基本链接开始：https://boston.conman.org/，然后添加您感兴趣的日期，例如 2000/08/01，最终 URL 将是：https://boston.conman.org/2000/08/01。您还可以通过省略日部分来指定整个月。您甚至可以选择任意时间段。您可能还会注意到链接的微妙阴影效果，这是故意的：链接与页面的“接近”程度越高，它的“亮度”就显得越明显。这是一个使用颜色阴影来表示链接与此处距离的实验。如果你没注意到它，也没关系；这并不太重要。