我更喜欢加密的，因为中间可能有 CDN ，虽然 CDN 是可信中间人，但是多一层保险比没有好。

试试蓝牙？

不如作为一个使用 linux 的程序员，反过来思考为什么不喜欢 windows 。

在 windows 上遇到问题，搜索问题得到的解决方案通常是图形化的步骤，虽然有步骤，但你不知道你在做什么，为什么这么做，你只是重复着别人给你的过程。比如有时候遇到网络问题，无法打开网页之类的，如果在 windows 上，通常会让你点某个界面，然后重置一下网络。至于问题的原因出在哪，为什么这么做，根本一无所知。这种做法对计算机不熟悉的用户来说，是很合适的。但是对于程序员来说，这就让人难受了，作为程序员，你总会想知道是 DNS 问题还是路由问题又或者是其他什么原因导致的。

在 linux 系统上，即使不是每一方面都理解，但整体上你有掌控这台计算机的感觉。而在 windows 上，完全没有这样的感觉。所以我是无论如何都不会觉得所谓的 WSL 能提供任何 Linux 的体验的，因为 windows 无法掌控的那部分过于巨大完全无法忽略。

把身份调换一下，为什么一般用户没法适应 linux 。由于 linux 的用户大都是有基础知识的，并且相较于图形化界面，更愿意使用命令行来解决问题，加上碎片化的各种发行版，你搜索到的解决方案有时候还需要你根据实际情况修改一些参数。一个毫无相关知识的小白很难顺手使用 linux 。

看看 https://matrix.org/cdn-cgi/trace 显示的地址，看看是不是代理的地址。

了解一下 SPF/DKIM/DMARC 这几个机制是怎么工作的，然后手动检查邮件里一些重要的 header ，比如 Return-Path 、DKIM-Signature 、Authentication-Results 。如果这几个 Header 都没有，多半就是伪造的。

除了一些特殊情况，Return-Path 是表示邮件是从哪个邮件服务器发送过来的，这个地址有可能和 From 不是同一个地址。RFC 5321 要求 Return-Path 是最后一跳邮件服务器加上的，也就是你的邮件服务提供商。

一般来说，你的邮件服务提供商会通过 SPF 机制验证 Envelope From ，然后把 Envelope From 的地址填到 Return-Path 里。要注意的是，Envelope From （ SMTP 协议通信时使用的地址）和邮件里的 From header （邮件里的 header ，客户端显示的就是这个地址）是两个东西，因此一封信即使通过 SPF 验证，仅仅能保证 Return-Path 写的是真的，而不能保证 From 是真的。

DKIM-Signature 是这封邮件的签名，里面通常带有哪个域名给这封邮件签过名，来保证邮件的完整性。但也要注意的是，签名域名和 From 也可以是不同的。比如 DKIM-Signature 里签名的域名可以是 outlook.com ，而 From 的地址却是 [email protected] 这种毫不相关的地址，这种情况下，DKIM-Signature 只能保证邮件是由 outlook.com 这个域名签名过的，不能保证 From 就是真的。

SPF/DKIM 和 DMARC 结合一起使用，才能保证 From 的真实性。DMARC 有 Alignment 要求，要求 SPF 和 DKIM 里的域名和 From 对齐。

Authentication-Results 则包含了以上几种机制 spf 、dkim 、dmarc 的验证结果。

以上只是理论上，但实际上，我发现很多邮件服务提供商，都缺少相关的东西。比如 qq 邮件收到的邮件，偶尔就会少 Return-Path 这种重要的 header ，很多学校使用的 Coremail 邮件系统则是没有一封邮件会有 Return-Path 信息。

这封邮件缺少很多重要的 Header ，比如 Return-Path ，而且 Received 这个 Header 里甚至出现了 1.45.182.097 这种地址里 0 开头的 IP 。

感觉是 163 邮箱自己 SPF 检查之类的反垃圾邮件机制不过关导致这封伪造邮件送到了你邮箱里。

@beryl #3 感觉这篇博客一本正经的胡写反而有点搞笑🤣

tk 域名还活着，cf 域名是 pending 状态

@debuggerx
@Yadomin
不是漏洞多少的问题，而是在上游没有的，但在下游有的漏洞。因为这会让人担心下游能否提供更好更安全的用户体验。

很多时候上游不是你可控的，但下游却会根据你的选择是否更安全（比如避免使用这个发行版来避开这个漏洞）。

@yanqiyu 可能是吧，就是希望能找到相对详细的说明。

用第三方的邮件转发服务，第三方服务多半是会保存一份副本的，不过可能只会保存一段时间，并且元数据会保存的更久。

一封邮件从 gmail 发出，通过 resend 转发，再到目标邮箱地址，至少有 gmail ，resend 和目标邮箱服务提供商可以看到这封邮件的明文。

所以从隐私的角度上来讲，别人如果想利用的话是完全可以利用的。真在意这一点的话，还是得使用 openpgp 端到端加密（但 email 的 header 还是会暴露很多信息）

邮件服务是有标准化的协议的：SMTP/POP/IMAP ，理论上所有邮件提供商都会支持这些协议。
所以通用的邮件客户端都可以统一管理，比如电脑端 Thunderbird ，安卓端 K-9 Mail 。

登录不上可能是因为默认没有启用 SMTP/POP/IMAP ，或者说认证时要求程序码认证，或者其他认证方式。

> 即使只是 lib.py.1.0.1 被 lib.py.1.0.1 取代
修正一下：即使只是 lib.py.1.0.0 被 lib.py.1.0.1 取代

@kuanat #64

> 如果 Package 规范要求包名带版本号，那么“安装”这个行为是不受限制的，也就不需要虚拟环境了。至于安装好了之后，使用时“选择“哪个版本，这是另一个事情。
所以我对“如果 Python 决定重写 import hook ，将版本号纳入成为包名的一部分，支持安装同一个包的多个版本，就没有今天虚拟环境什么事了”这句话产生疑问。
无论怎么重写 import hook ，又或者在包里加上版本区分。仅仅是在“被导入方”加入版本信息还不够，还需要在“导入方”记录要导入的版本才行。
脚本型语言和编译型语言不一样，不存在编译、运行两个过程，编译型语言可以在编译时，在二进制文件里记录版本信息，那脚本型语言在哪里记录版本号就是个问题了。

> Python 完全可以从规范层面要求所有的包名都带版本号，然后 import hook 的实现无视它，固定使用版本号最大或者最小，甚至文件最后修改信息最新或者最旧的版本。
你所说的几种情况，一旦某个依赖的包升级，就有可能导致已有项目崩溃。且不说 lib.py.1.0 被 lib.py.2.0 取代，会导致依赖 lib.py.1.0 的项目崩溃。
即使只是 lib.py.1.0.1 被 lib.py.1.0.1 取代，这种崩溃也是可能的，semver 无法解决这个问题。因为很多时候你无法区分 breaking, enhancement 和 bugfix 。
用别人的例子， [你在你的包里加入了一个 warning ，这个是属于 breaking, enhancement 还是 bugfix ？]( https://twitter.com/brettsky/status/1262077534797041665)
这里选择 bugfix 的是最多的，可你又如何保证你新输出的 warning message 不会 break 别人的项目呢？所以 semver 本身是无法被依赖的。你无论再怎么设计规范，总会出现你的 bugfix 成为别人的 breaking 的情况。

其实我想说的重点是，多版本共存本身不是问题所在。反而由于如果强行多版本共存，在运行时，要如何“选择”哪个版本是主要问题。而为了解决这些问题，又进一步会带来一堆问题。

所以，为什么非要多版本共存？没有多版本共存本身就是一种解决方案，而不是问题。