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/ |