Jorey Bump a écrit : > berny wrote, at 04/08/2009 05:41 AM: > >> 2. If yes, what type do you use? >> a) only PTR check [reject_unknown_reverse_client_hostname] >> b) or PTR=A check [reject_unknown_client_hostname] >> 3. What are your experiencies and opinion to it? > > I have found it unsafe to use either. At the very least, it will reject > mail from poorly run (but legitimate) mailing lists. There are also an > alarming number of schools, government and other nonprofit sites that > cannot make it past these checks due to poorly configured DNS and the > lack of expertise to correct it. At the extreme end, some major > registrars cannot pass these checks, which could put domains at risk for > recipients who depend on email reminders to renew their domain > registrations. > > It's a shame, because enforcing these checks would have a noticeable > impact on spam, especially FCrDNS:
but that would be somewhat arbitrary. most of these would be better blocked by their ISP. and if ISP wnat them to reach you, he can setup a FCrDNS, using a dictionary (so that you can't block them because they are "dynamic"). and even for "correctly" configured systems, DNS problems may happen. and when a get a temp failure, you don't know whether it is accidental or "fake". PS. Some people have proposed abandoning rDNS for IPv6... > > http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS > > Sadly, I have been unable to uncover a method to use FCrDNS in a scoring > system. Ideally, I would like to use SpamAssassin, but if anyone knows > of another way, please share. > you can do more "strict" checks in the case of "unknown", but you still need to be careful. or you can do the opposite: do some checks, and instead of "reject", use a "reject_unknown_...". but I think passing the stuff to SA is a better to approach. > In any case, you can review the potential impact of the above directives > by including this in smtpd_(client|recipient)_restrictions: > > warn_if_reject reject_unknown_reverse_client_hostname > warn_if_reject reject_unknown_client_hostname > > Watch your logs and monitor potential rejections. Be aware, however, > that it can take months to reveal something truly serious (like a yearly > notification from a registrar). > and I've seen these trigger on systems that are "usually correctly configured", but have a dns problem during some period (few days). > Henrik K wrote, at 04/08/2009 09:54 AM: >> On Wed, Apr 08, 2009 at 09:09:58AM -0400, Jorey Bump wrote: >>> It's a shame, because enforcing these checks would have a noticeable >>> impact on spam, especially FCrDNS: >>> >>> http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS >>> >>> Sadly, I have been unable to uncover a method to use FCrDNS in a scoring >>> system. Ideally, I would like to use SpamAssassin, but if anyone knows >>> of another way, please share. >> Don't bother looking too hard. :) Postfix records FCrDNS in Received-headers >> ("unknown" if not matching) and SpamAssassin uses that information in >> RDNS_NONE rule. > > Funny, I took that rule at face value and assumed it only indicated a > missing PTR. Even funnier, I've been incrementally raising the score for > months (currently at 4 points) looking for the sweet spot, so it seems > I've been checking FCrDNS all along. Thanks for the info! Time to notch > it up another point... > > note that RDNS_NONE is unsafe if you get mail from forwarders (or fetchmailed servers) that don't check rDNS. spamassassin does no rdns check. it uses the top most Received header where the host "untrusted" (not in trusted_networks). This is the reason why the default score is very low.
