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'. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
