Hi Rich
I'll cc this to the ietf list, as you suggested.
I've found the problem. It may or may not be something that ietf want's to
do something about -- I would think they would, since it seems to have global
significance. But I can fix it from this end.
Specifically, the problem Dave encountered earlier was that the ietf mail
server was rejecting mail without reverse dns, and since the ietf mail server
and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6 addresses,
and ip6 is used preferentially, and I hadn't set up reverse dns, they were
dropping all mail. I fixed that, and things started working.
The only domains I control that had explicit ipv6 addresses were Dave's
domains. For example, graybeards.net:
# host graybeards.net
graybeards.net has address 72.52.113.69
graybeards.net has IPv6 address 2001:470:1:76:0:ffff:4834:7145
graybeards.net mail is handled by 10 mail.graybeards.net.
# host mail.graybeards.net
mail.graybeards.net has address 72.52.113.69
mail.graybeards.net has IPv6 address 2001:470:1:76:0:ffff:4834:7145
# host 2001:470:1:76:0:ffff:4834:7145
5.4.1.7.4.3.8.4.f.f.f.f.0.0.0.0.6.7.0.0.1.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa domain name pointer mail.graybeards.net.
#
Mail now works for this domain.
But, it turns out, the ietf.org mail servers are rejecting mail from other
domains as well. Here's a log entry for one of your messages:
Jul 2 13:10:23 mail sendmail[31264]: STARTTLS=client, relay=mail.ietf.org.,
version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 2 13:10:29 mail sendmail[31264]: m62Hvfbm011799: to=<enum@xxxxxxxx>,
ctladdr=<richard@xxxxxxxxxx> (1023/1023), delay=02:12:32, xdelay=00:00:28,
mailer=esmtp, pri=662167, relay=mail.ietf.org. [IPv6:2001:1890:1112:1::20], dsn=4.7.1,
stat=Deferred: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [2001:470:1:76:2c0:9fff:fe3e:4009]
Rejecting when you can't find a reverse is, of course, a common anti-spam
technique.
However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not
explicitly configured on the sending server; instead, it is being implicitly
configured through ip6 autoconf stuff:
eth0 Link encap:Ethernet HWaddr 00:C0:9F:3E:40:09
inet addr:72.52.113.176 Bcast:72.52.113.255 Mask:255.255.255.0
inet6 addr: fe80::2c0:9fff:fe3e:4009/64 Scope:Link
inet6 addr: 2001:470:1:76:2c0:9fff:fe3e:4009/64 Scope:Global
The 2 ip6 addresses, the link-local address, and the global address, are
generated from the mac address (you can see the 0x4009 at the end) and
configured autmomatically, merely because ipv6 is enabled on this box by
default, and a global prefix is available.
That is to say, it appears the ietf.org mail server is probably now rejecting
mail from *any* box that is getting a default global ipv6 address, since
those addresses will most likely not be in ip6.arpa. There may be a whole
lot of boxes in this situation.
Kent
PS -- I'm not sure this will actually make it to the ietf list :-) ...
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf