Matt Kettler a écrit : > Stefan Jakobs wrote: >> On Tuesday 21 October 2008 14:57, Matt Kettler wrote: >> <snip> >> >>> In general it is recommended to not point a MX record to a CNAME, but >>> that's just to reduce repetative querries. It is extraordinarily >>> commonplace in the real world, and AFAIK 100% RFC legal. >>> >> I don't think so. See: http://www.rfc-ignorant.org/policy-bogusmx.php >> >> "Section 10.3 of RFC 2181 points out that pointing an MX RR at a hostname >> which is actually a CNAME RR is invalid, and such hosts are also listed." >> >> <snip> >> >> Greetings >> Stefan >> > Fair enough. It is still extraordinarily common. > > It's also not actually the point of the OP's restrictions, but it was a > part of his example. > > (Also, I have to point out just because it's a RFC violation and RFCI > chooses to list it does not make it useful in spam filtering. RFCI is > interesting data, but it's also extremely FP prone nowdays) >
The bogusmx and dsn sublists are still useful for score based filtering (some people even use them in smtp reject as well, although I find that "unsafe"). The current 50_scores.cf has: score DNS_FROM_RFC_BOGUSMX 0 2.125 0 1.482 # n=0 n=2 score DNS_FROM_RFC_DSN 0 2.527 0 1.495 # n=0 n=2 It would be intersting to divide the bogusmx list according to the type of error and see which errors are indicative of spam. I'll bet that the CNAME error is neutral, but I have no evidence. but errors like the following ones either mean spam or unreachable sender (and if you can't reach the sender, it is probable that you want him to get an error to fix his config): $ host -t mx 06688.com 06688.com mail is handled by 0 dev.null. $ host -t mx 0h.cn 0h.cn mail is handled by 10 mail.0h.cn.$ host mail.0h.cn. Host mail.0h.cn. not found: 3(NXDOMAIN) $ host -t mx socks.xmission.com socks.xmission.com mail is handled by 10 127.0.0.1 $ host -t mx 3banatomy.co.kr 3banatomy.co.kr has no MX record
