Justin Mason wrote:
mouss writes:
Justin Mason wrote:
>[snip]
>
> In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
> legit email in general, going by the test results for our RDNS_NONE
> rule... ;)
It just came to my mind that RDNS_NONE does not mean the client does not
have a reverse DNS, be it confirmed or just a PTR.
RDNS_NONE uses the rdns field determined from the Received headers, but
- some MTAs do not do rDNS lookup
true.
- there may be a temp fail
But this would be indistinguishable by an MTA that refuses at SMTP HELO
time, too.
- there may be a mismatch (PTR exists but doesn't resolve back to IP)
I don't know of an MTA that removes rDNS from the Received: header if
that occurs. do you?
postfix will set the rdns to "unknown". I don't know what other MTAs do.
but in general, it is unwise for an MTA to set the rDNS if it is not
"forward confirmed".
so the 3.6% include more than IPs without a (valid) PTR.
It would be interesting to get stats for each category, but this
requires doing the lookup in SA. which brings us back to an old request:
add the possibility to lookup rDNS in SA. Are there any caveats in
adding this? I am thinking of something like
resolve_ip (0|1|2)
where 1 means a PTR lookup only, and 2 a "double" lookup ("FcrDNS"), and
the lookup is only done on the most external relay?
There *were* rDNS lookups in SpamAssassin, but they caused trouble:
- 1. they need to be asynchronous, like the most of the rest of
SpamAssassin's network test infrastructure, and they weren't.
indeed.
- 2. it causes differences in running many of SpamAssassin's rules, even
non-net-test ones, depending on whether -L was on or not.
simpler to take it out and rely on the MTA.
true. I have some mail that is fetched from an ISP where rdns lookup is
disabled. but I guess I'd better pass mail to a script that does
resolution before passing mail to SA instead of changing SA!
thanks for the comments.
