@
limetw 大哥，首先，你要有一定的知识储备（没有贬低的意思），否则，你的猜测没有价值，甚至我都没法和你解释你的问题点在哪，因为太费劲了。
HTTPS 的加密，目的是防止中间人窃听、篡改、重放，也就是说，中间人（ A 端和 B 端中间的一切路由、交换设备）是可以得到传输过程中的所有数据，但都是被加密的。
换言之，就是 A 和 B 通讯的时候，确保真的是对方发过来的数据。
现代加密传输技术，连银行都不例外依赖这些技术，包括某付宝、某信支付。
解释这个的意思是啥呢，如果可以伪造，那么绝对是惊天大瓜（之前也有爆瓜，每一个都被历史记载），而且会有一系列攻击手段，并且造成一系列的损失，而且信任体系不说崩塌起码得震三震，然而业界震动了吗？并没有吧，这个叫透过现象看本质，咱不需要懂底层技术，只需要观察业界动态，就能知道这玩意是否可靠。
然后说原理，你指出的这个技术，从网络数据看，是 A 要连接 B ，但是用户侧指定了 C 的 IP 地址，所以 A 和 C 通讯经过了 B ，B 在 A 、C 收发数据时且在握手阶段时，只转达，不改变，所以此时 B 承担了交换机/路由器的作用，握手阶段只有部分是明文的，所以 B 也看不懂到底收发的细节是啥，但是，根据 TLS 协议，握手包的数量是确定的，例如是 5 个包，这 5 个包 B 原封不动的转发。
因此，其他的中间设备，即便对这 5 个包进行判断，也没有任何意义，因为它本质上就是正常的包。
5 个包之后，两端已经过握手阶段，后续就是互相发送加密数据了，这玩意没有任何明文信息，全是加密包，所有路由、交换设施都看不懂里面的任何数据，此时 B 不再将 A 的数据包转给 C ，而是与 A 通过自有协议进行握手或传输，但，所有数据加密，并对握手数据包的大小、随机率进行伪装，确保中间的路由、交换设施没有能力判断后续数据包特征。
这个技术的核心点在于“欺骗中间人和中间的一切设备”，在 A 和 B 之间，谁都没有欺骗谁。
回到这个主题，通讯方变成了邮件收发客户端和邮件服务器，你要做的是什么，本质上就是客户端要欺骗服务器，如何欺骗呢？不是大哥你说一句“邮件伪造无非就是绕过收件人信箱的验证”就搞定了，上面大家提到的这些技术，就是为了防止绕过，如果当今真有绕过的技术，那大家早就开始修补了，至少开源社区会震动并大范围通告。
其实我说了这么多，也不确定你是否能看懂，因为如果你不懂编程和网络传输技术的话，其实解释了也白解释，因为你只需要继续“怀疑”就可以了，如果不是我专门看过这个技术的文档和一些思考，还真就被你给忽悠了，可能这会都兴奋得不行。
但其实也还好，因为通过搜索引擎能很快的确定你说的猜测不存在，这种属于惊天漏洞，很容易确认是否存在甚至不需要懂技术，而且对于懂技术的开发者，对于自家的程序修复起来都不难，现在加密、传输技术已经非常成熟，“成熟”的意义是，经过不断的技术迭代，不会犯低级错误，同时因为开源思想的存在，后人不断完善机制。
其实这些东西都能侧面观察出来，比如 Windows XP 的 IE8 浏览器，虽然也能使用 HTTPS 技术，但是已经打不开大部分 HTTPS 网站了，这说明旧的加密传输技术已经被业界认定为不安全，淘汰了。
唉，说这么多，其实邮件要验证来源是及其简单的事情，根本就不可能绕过，除非个别服务器的实现上面很蠢，这个属于软件自己的安全漏洞了，举个例子，邮件服务器有安全漏洞，别人把他黑了，塞一个邮件进去，用户侧是看不出毛病的，你不可能真的一封一封邮件点开看源码自己去走一遍验证流程。
“的的确确可以拿别人的证书来用”，你看，你一边不确定，一边又很确定一个错误的结论，这在技术社区绝对是不好的习惯，如果你懂开发技术，罚你去仔细看看这个技术的原理，回来欢迎我们好好讨论，如果你是吃瓜群众，真的不要传播错误的结论，这会浪费很多技术人的时间（因为这瓜太刺激了，大家都愿意去研究一下，但可能得到的是失望），错误的技术结论传播的越广，浪费的时间越多……