不如作为一个使用 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 的情况。

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

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

@kuanat #58

我的疑问是，__all__和你提到的文件系统大小写敏感几乎没有关系。因为解决大小写不敏感所带来的问题的方案主要是通过规范要求名称都是小写。而且不管有没有__all__，import *都可以使用，只不过没有__all__会默认导入所有非下划线开头的名字。但正是这一点，让我很疑惑为什么要扯上__all__。也许你提这个目的单纯是想说__all__的诞生的历史是在规范模块名之后提出的？除此之外我看不出__all__和文件系统大小写不敏感有什么关系。

正是前面这一点我没看懂，所以之前还有一点也没继续问下去。其实还有一个问题就是，你#48 提到：
> 这个时间点上，如果 Python 决定重写 import hook ，将版本号纳入成为包名的一部分，支持安装同一个包的多个版本，就没有今天虚拟环境什么事了。
为什么这样能解决需要虚拟环境的问题？按我所理解的，go 之所以能把所有 mod 都哦下载到$GOPATH/pkg 下，然后在加上版本区分，完全是因为二进制文件能够记录编译时的版本号（说的更完整一些，完全也可以静态编译）。

而对于脚本型的语言，没有一个地方记录库对应的版本，因此这类语言采取的方式都是设置对应的 PATH （比如 PYTHONPATH 等等），然后在 PATH 中寻找最先遇到的库的版本导入。如果你要多版本共存，在同一个 PATH 下，遇到同个包的两个版本，该导入哪个？

@kuanat
> 为什么 Python 需要 __all__ 来支持 from XXX import *
__all__不是拿来指定哪些是公开接口，哪些不是吗？你给出的回答似乎和为什么需要__all__没什么关系？？？

还有所谓多版本共存的问题，这不是真正的问题所在。

对于编译型的语言，编译（链接）时，会在生成的可执行的文件里记录对应的版本号。在运行时，则会根据可执行文件中记录的版本去动态链接对应的库。这里的多版本库的共存的机制其实不是语言本身的，而是 ELF 文件格式提供的（以 linux 为例，windows 应该也有类似的机制）。

但对于脚本型语言，你的脚本里没有记录依赖的库版本（并且也不该在代码级别处理版本依赖）。
因此即使你在安装的库的版本里，加了版本后缀作为区分又有什么用呢？因为你脚本本身没有记录到底使用的哪个版本。

python 的虚拟环境和其他语言的依赖管理工具是类似的，解决都是依赖管理和隔离的问题。

pip 安装包时，把包安装在了系统/用户路径。而不同项目使用同一个系统/用户路径就会有依赖冲突的问题。所以有了虚拟环境这个概念，来隔离不同项目使用的不同版本的依赖。

而其他语言的工具链可以直接把包安装到当前项目的路径，然后当前项目的库路径加入到库加载路径里（比如 CLASSPATH ）。因此这些语言没有虚拟环境这个概念。

实际上楼上也有人提到了，python 其实也可以学习这个做法，把所有包安装到项目的目录下，然后设置 PYTHONPATH 。