这是一个创建于 3509 天前的主题，其中的信息可能已经有所发展或是发生改变。
从昨天下午北京时间大约18点开始，我们公司托管在google apps标准版（免费）上的邮件出现无法发送，接收延迟的情况。
症状：
1. 接收不到同域的邮件（同后缀不同账户之间的邮件, 比如[email protected] 和 [email protected]不能收发对方邮件）
2. 突然收到数封几分钟甚至十几小时之前的外部邮件
3. 用朋友的国内企业邮箱发送能收到，也能正常发送
4. 做了SPF和DKIM记录，现在SPF记录无，DKIM仍为正常状态（域名解析里记录正常）
5. 用自己的gmail.com后缀的邮箱测试收发正常
异常：
检查之后发现SPF记录为none，附上正常和异常对比记录
none (google.com: victor@*.com does not designate permitted sender hosts) client-ip=2607:f8b0:4001:c05::22d;
pass (google.com: domain of victor@*.com designates 2607:f8b0:400d:c01::22b as permitted sender) client-ip=2607:f8b0:400d:c01::22b;
**注意，以上情况皆为不稳定非持续情况，偶尔会收到一两封
症状：
1. 接收不到同域的邮件（同后缀不同账户之间的邮件, 比如[email protected] 和 [email protected]不能收发对方邮件）
2. 突然收到数封几分钟甚至十几小时之前的外部邮件
3. 用朋友的国内企业邮箱发送能收到，也能正常发送
4. 做了SPF和DKIM记录，现在SPF记录无，DKIM仍为正常状态（域名解析里记录正常）
5. 用自己的gmail.com后缀的邮箱测试收发正常
异常：
检查之后发现SPF记录为none，附上正常和异常对比记录
none (google.com: victor@*.com does not designate permitted sender hosts) client-ip=2607:f8b0:4001:c05::22d;
pass (google.com: domain of victor@*.com designates 2607:f8b0:400d:c01::22b as permitted sender) client-ip=2607:f8b0:400d:c01::22b;
**注意，以上情况皆为不稳定非持续情况，偶尔会收到一两封
第 1 条附言 · 2015-04-14 13:48:36 +08:00
现在这情况会不会有人进行中间人攻击，还是因为google 没把自己新的ipv6添加到spf记录里？
 |
1
vInspector 2015-04-14 12:21:48 +08:00
|
 |
2
lk09364 2015-04-14 13:52:56 +08:00
@vInspector Google App Engine != Google App...
|
 |
3
surftheair 2015-04-14 13:58:18 +08:00  1
我的没有问题，收费版的
|
 |
4
yylzcom OP @surftheair
我初步怀疑有： 1. 我用的dns.he.net有关 2. Google忘记把上面那个IPv6地址添加，导致我做的spf不通过影响邮件发送接收 3. Google Apps出问题，因为同时转发三个邮件给我和我同事，我收到第一封，我同事收到第二封，第三封谁都没收到。这些未送达的邮件发件方没有收到任何退信或者错误信息 |
|
5
lk09364 2015-04-14 14:03:13 +08:00
|
|
6
yylzcom OP |
|
7
lk09364 2015-04-14 14:12:28 +08:00 1
@yylzcom 2 不对。
_spf.google.com. 299 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" _netblocks2.google.com. 3599 IN TXT "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all" SPF 包括整个 2607:f8b0:4000::/36 |
|
8
yylzcom OP |
|
9
lk09364 2015-04-14 14:29:30 +08:00
@yylzcom 这个就是Google 里文档的那个吧。
我认为大概有3个可能性： - Google 邮件伺服器用的 DNS 坏掉了。 - dns.he.net 把部分请求吃掉了。 - 墙把部分请求吃掉了。 可能性2 能解释症状2、4。 可能性3 能解释症状3。 所以你可以…… - 墙内 dig 一下 SPF 在吗？ - 用不同 DNS Server dig 域名的 TXT 试试，看看是不是 dns.he.net 出问题。 - ……想不到其他测试方法。 |
 |
10
phoenixlzx 2015-04-14 14:43:12 +08:00
@lk09364 目测是自动匹配出了问题...
|
|
11
lk09364 2015-04-14 14:46:22 +08:00
@phoenixlzx 自动匹配是指……？
|
|
12
phoenixlzx 2015-04-14 14:55:28 +08:00 1
@lk09364 一楼的机器人... Google Apps 匹配到了 Google App Engine
|
|
13
lk09364 2015-04-14 14:58:17 +08:00
@phoenixlzx 这就糟糕了，是不是应该…… editrule vInspector "Google Apps" "Google App Engine"
|
|
14
yylzcom OP |
|
15
lk09364 2015-04-14 15:06:26 +08:00 1
@yylzcom 这不科学，你请求 TXT，它返回 CNAME？
我自己也在裸域加 CNAME，刚刚测试20来次没有问题，大概是供应商的问题了。 |
|
16
yylzcom OP @lk09364 我一开始也很疑惑，但是网上确实有这种说法裸域名不能添加cname
附上我测试的结果： C:\Users\victor>nslookup -type=TXT maskdomain.com 服务器: unknown Address: 192.168.1.1 非权威应答: maskdomain.com text = "v=spf1 include:_spf.google.com ~all" C:\Users\victor>nslookup -type=TXT maskdomain.com 服务器: unknown Address: 192.168.1.1 非权威应答: maskdomain.com canonical name = another-domain.net another-domain.net canonical name = jp.the-other-domain.org the-other-domain.org primary name server = a.dnspod.com responsible mail addr = domainadmin.dnspod.com serial = 1372325396 refresh = 3600 (1 hour) retry = 180 (3 mins) expire = 1209600 (14 days) default TTL = 180 (3 mins) C:\Users\victor>nslookup -type=TXT maskdomain.com 服务器: unknown Address: 192.168.1.1 非权威应答: maskdomain.com text = "v=spf1 include:_spf.google.com ~all" |
|
17
phoenixlzx 2015-04-14 15:22:24 +08:00
|
|
18
lk09364 2015-04-14 15:36:38 +08:00
@yylzcom @phoenixlzx 嗯… 现在找到原因了。在 RFC 下，的确是不应该在 @ 加 CNAME 的 [1]，不过我用的 cloudflare 有所谓『cname flattening』[2] 的东西，所以就没问题 ——因此不是供应商的问题，之前的推断错了，抱歉。
[1]: http://serverfault.com/questions/170194/why-cant-a-domains-root-be-a-cname [2]: https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/ |
Select Language