有关邮箱地址伪造，有没有大佬来个科普

DKIM 可以防止伪造，只要你的发送方支持
https://write.c7.io/snullp/liao-jie-xian-dai-smtp-he-dian-you-anti-spam-xie-yi-spf-dkim-dmarc

使用 DKIM 验证. 我邮箱自带自动验证并且邮件标识出来.

DKIM + DMARC

如果公司需要安全邮件服务可以用我的试试.

正确的方法是使用 S/MIME 或 PGP 对邮件进行数字签名或者加密。

> 应对网络诈骗，如果我收到自称是 A 发来的邮件，我回给 A 邮件的信息是不是只有真正的 A 知道

是的，只要你在回的时候仔细确认收件人。小心来件里可能有 CC/Reply-To ，这样可能会被第三者知道

就跟电话一样，来电号码可以伪造，但再打回去确认就没问题了。

1 、有，S/MIME 或 PGP 。前者需要向 CA 申请证书。后者可以自行生成公钥。主流邮件客户端 Outlook 或 ios 自带客户端支持 S/MIME ，像 thunderbird 之类开源客户端同时支持两者。
2 、无法绕过。
3 、无法绕过。
4 、完全解决此问题。数字签名解决身份确认问题。S/MIME 和 PGP 还可以加密。端到端的加密可以防止网络服务商和邮件服务商监控邮件内容。

@ZE3kr 邮件还遇到过，我用客户端查看收件人栏位，收件人地址不是我但是我收到了（同时我也不是抄送地址），不知道是怎么做到的

@busier 不用 outlook 客户端。我使用 outlook 网页版是否有自动验证功能？

> 收件人地址不是我但是我收到了（同时我也不是抄送地址），不知道是怎么做到的

你在密送 (BCC) 里

一般用于群发给一大堆人一样的邮件，但是不让收件人知道收件人列表
这个时候 收件人一栏一般空着或者写发件人的邮箱

了解一下 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 信息。

@LeeReamond 端到端的加密必须由客户端软件支持。好在这两者都是行业标准，pc 端和移动端都能良好支持。

目前尚未发现 web 界面的支持客户端。

话说这是终端到终端的加密，你要是将私钥放在 web 服务器上解密并以 web 方式展现邮件的话，那就失去端到端加密的意义了。

@cnt2ex 厉害
邮件服务商对规范遵循程度参差不齐，作为用户，邮件服务商也不可能依着用户改，况且大家还五花八门用着不同的邮件服务商。所以说这个思路不太可能有效解决问题。

感觉 xray-core 的 reality 既然可以偷证书上网
那么是不是可以在邮箱上面做文章
没读过源码 忘了哪次意淫出来的 就没了后续

一、邮件传递参数逻辑：
发送 ip 地址：垃圾检测
mail from：垃圾检测
rcpt to：垃圾检测
from:无检测〔伪造部分〕
to:无检测〔伪造部分〕

二、没有垃圾邮件网关，简单的方法：
1.入向接收邮件，出向发送邮件，一台服务器拆分为两台服务器
2.入向接收邮件系统对来自 from 地址是内部域名的进行拦截

三、有垃圾邮件防护网关：
1.配置策略指定参数的邮件，进行隔离拦截

说明：
此处接收邮件，发送邮件，指的是服务器和服务器通讯比如，A 服务器->B 服务器，不是客户端的发送接收邮件

邮件伪造可以主要看一下
1 、spf 伪造，通过配置 dkim 防御
2 、代发，发件人声称自己是 [email protected] ，也就是发件人地址，其实是 [email protected] ，这种情况通过网页端查看提示该邮件是否为代发
3 、形似域名：比如你公司是 aabbcc.com ，攻击者购买一个 aabbbcc.com 自建邮箱给你发，注意仔细验证后缀名就可以防御
4 、攻击者拿到你单位内部后发起的钓鱼攻击，如果涉及到密码、资金等重要信息的，打电话确认。。

邮件系统的主要问题是多方合作，很难强制所有参与方全都上统一的高级别安全措施
所以一般都会比较宽容“别家”没上安全措施

@limetw

首先，不要怀疑现代加密体系，不会有什么“偷证书”这种技术，当你有这种理解的时候，说明你对传输技术和 TLS 技术不够了解，再多看几个科普文吧。

你说的这个技术，只是一种伪装的方法，但是伪装的影响目标是中间人，而不是传输的两端，传输两端是伪造不了的，如果能伪造就是天大的漏洞，早都铺天盖地的修补了。

@NewYar https://github.com/XTLS/REALITY

@NewYear 的的确确可以拿别人的证书来用，实现 CDN 的效果。而且可以任意修改其内容~

当然了，DNS 是动不了的，这也就跑题了。因为我没去读 r 佬的源码，所以邮件是不是也可以拿来用。邮件伪造无非就是绕过收件人信箱的验证，或许不能，关键得先假设再动手。

哦，我还没动手去验证...
仅供参考

@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 网站了，这说明旧的加密传输技术已经被业界认定为不安全，淘汰了。

唉，说这么多，其实邮件要验证来源是及其简单的事情，根本就不可能绕过，除非个别服务器的实现上面很蠢，这个属于软件自己的安全漏洞了，举个例子，邮件服务器有安全漏洞，别人把他黑了，塞一个邮件进去，用户侧是看不出毛病的，你不可能真的一封一封邮件点开看源码自己去走一遍验证流程。

“的的确确可以拿别人的证书来用”，你看，你一边不确定，一边又很确定一个错误的结论，这在技术社区绝对是不好的习惯，如果你懂开发技术，罚你去仔细看看这个技术的原理，回来欢迎我们好好讨论，如果你是吃瓜群众，真的不要传播错误的结论，这会浪费很多技术人的时间（因为这瓜太刺激了，大家都愿意去研究一下，但可能得到的是失望），错误的技术结论传播的越广，浪费的时间越多……

@limetw

“邮件伪造无非就是绕过收件人信箱的验证，或许不能，关键得先假设再动手。”

我真的不想吐槽，对于一个开发者，验证来源是有多难的事情，整个互联网，不说远了，就说各银行的 API 接口，都是用很简单的技术验证的来源，至少二十年前就这样干了，即便传输过程不加密，你都伪造不了，你老人家一句“无非就是绕过 XXX 信箱的验证”，这要怎么绕过呢，你要假设也要有思路啊大哥，要不然别人哭笑不得呢。咱要不就绕过一下银行的简单验证机制嘛，直接走向人生巅峰。

不过说真的，早期的时候，真的是有“伪造邮件地址”，不过都是利用邮件协议本身的特性，现在这些问题都有妥善解决办法啦。

@NewYear

我的假设只是一个偶然的意淫，仅此而已。或许有很多地方欠考虑（无法实现、很难实现），但我的第一条应该不难理解，你可以认为我是小白，本身就没有技术性讨论。

我给出的观点，的的确确是一个伪造方法。它跟传输加密无关，我没质疑过。reality 本身也不是修改真实服务器的数据，你进行邮件攻击也和要伪造的邮局（域名）无关对吧？那么，就不存在篡改加密内容。

“邮件伪造无非就是绕过收件人信箱的验证”，现在知名的邮箱系统用啥验证方案其实都无所谓。历史上发生过很多次，伪造邮件和真实的几乎没明显区别（对普通用户而言，专业用户也不一定每封邮件都严格证伪吧），无论是什么伪造方式，达到目的就行。本质上就是欺骗了收件人的邮箱系统，绕过了它的真实性验证。

这个世界上有一个叫 0day 的东西。它可以是极少数人掌握，也可以是自己一个人掌握。虽然现代的加密十分可靠，但你不能说它绝对安全，无法破解（暴力破解也算破解）。还有，银行系统在我印象里是最脆弱的，都不如腾讯、阿里这样的公司安全。QQ 邮箱应该是国内最棒的了，伪造成功的案例也很多啊！

回到臆想本身。reality 偷证书给你，你利用它实现了无证书白名单翻墙。中间人，也就是那个叫 gfw 的坏家伙，它用各种方法来审查你，gfw 最后认为你提供的证书是真实的，你的数据无异常。当然，它没办法审查加密数据，只能根据特征判断。

既然，reality 可以“偷证书”，不要怀疑，它确实偷了，哪怕只是转发握手包。在你自己的服务器上，也可以用别人的域名架设 web 服务。然后内容你是可以修改的，如果你做不到那是你的问题，我没必要解释更多（域名是别人，内容是你自己，你不需要修改真实服务器上的数据！）。这样，我们有了一个以假乱真的 web 服务对吧？只要你 hosts 充当公网 DNS ，那么完全可以说我的站点和真实服务器没有差别。你、我、他访问这个站点，用别人的域名都是一样的。

关于邮件伪造，我说了这只是一个臆想。能不能做到我不知道。因为我根本没研究过邮件系统，但是很久以前看过几篇关于伪造的文章。自己也确实成功发起了几次邮局欺骗，可能当时没 TLS 比较容易？

所以我的这个意淫，没有说伪造邮局的难度，没有技术讨论的意愿，没有去验证任何东西。就没必要跟我普及那么多知识了。当然我也可以直接回一句，老子手里有 0day ，既能装逼又优雅，而且没后续。

但我写这么多干嘛呢，因为你也给我写了很多。我尊重你。第一条我就写了是意淫~ 而且我的意淫还是有根据的。有想法是好事，你不能扼杀。

但是你理解错了我这个想法。我得指出来，它和我懂不懂没关系。因为你指出来的加密可靠性什么的，在我的想法里是无需考虑的。

最后。不建议你再拿出什么来指点我。还是那句话，第一条我就明确了，这只是一个意淫。我不懂邮局系统，压根没兴趣。所以这套逻辑行不行得通我自己都不清楚！！！但是很多邮件伪造的漏洞咱又不是不知道，我认为不难。也别跟我抬杠，v2ex 如果能销号早销号了~ 你认为你对就对，你怎么认为就怎么认为。我就是来水贴的，恩。反正逼逼那么多，也不如去 exploit 翻一翻漏洞能解释清楚。

@NewYear

https://support.google.com/a/answer/10583557?sjid=18380727723177315276-NC&hl=en

首先，我承认我的假设行不通。简单地了解了一下现在的身份验证措施，其实 11 楼也写了，我没看着。而且，SPF 和 DMARC 我自己的域名也早就启用了。

我一直以为，这个验证是有效的。但没有此记录的域名就有被伪造的风险。而且，肯定有其他办法攻击，这也是我举一反三的思考方式。

我其实忽略了最基本的。那就是发件方可以声明自己是任何地址，收件方更是简单粗暴。直接请求 DNS 去做验证。那么和“偷证书”完全无关。故，我的假设无效。

但是，你也不要认为你就是对的、你并没有帮助我，更多的是误导。（你一个帖子跟我讲 HTTPS 加密，和邮件无关，和 reality 无关，咱是没看懂你想表达什么）

那么，看来我说“邮件伪造无非就是绕过收件人信箱的验证”是正确的，也是错误的。这句话可以强行洗，但没必要。

我一开始就是来水贴的，就没过脑子。而且这东西并不是很感兴趣，只是随便一写的想法。是的，连现在的邮件验证逻辑我都不知道，就胡思乱想。

感谢我的胡思乱想，所以我举一反三，知错改错。我值得骄傲！这个假设行不通，我还有无数个假设，然后去证伪，最后去验证。反反复复，最终解决问题。

到此为止吧。

@NewYear 存不存在偷证书，你可以和 rprx 对线。
收件方的验证就是去验证 DNS ，reality 解决不了这个问题。

你有没有发现，其实就这么简单，我不懂现在邮件的验证逻辑，因为我没兴趣，我对邮箱系统的印象还停留在 0 几年。你从偷证书开始，再到跟我科普什么 HTTPS ，完全跑题。

其实如果不去了解，按照我的理解还是很符合逻辑的。甚至每封邮件都是用证书加密出来的话，我都想到了解决方案。

谁也不是天生的无所不知。说多无益，就那么简单的东西。再见