On Tue, 2012-07-24 at 09:55 -0400, Chris Knadle wrote: > However I don't see anything in the implementation about RDNS or SPF.
It's not in the implementation. If it appeared, it would be one of the
examples in the 'Setting the conditions for "suspicious" mail' section.
As it says, you can use whatever conditions you see fit. Perhaps we
should add rDNS to the examples.
> personally wouldn't trust RDNS or SPF in a greylisting implementation, because
> both are something that are in the control of the DNS server for the sending
> domain.
I think you're missing the point of the 'suspicious' trigger. It's not
about *trusting* rDNS or SPF. If an email arrives which is not
considered suspicious in any other way — it has no SpamAssassin points,
isn't HTML, it has a Message-Id: and Date: header as it should, and
doesn't match any of your other triggers, then normally you'd accept
that message *without* the gratuitous delay that greylisting would add.
But if that same mail comes from a host which lacks reverse DNS, or has
an SPF 'fail' result, *then* you might want to greylist the mail.
Because now you *do* have a reason to consider it 'suspicious'.
