David Woodhouse wrote:
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'.
If one applies rDNS sanely there isn't much need for the rest.
'The percentages' have it. If there is nothing obviously and
fundamentally 'wrong' right up-front, survivors carrying garbage are a
minority.
Still deserves further filtering, but if passing rDNS, all too often
everything else about the 'carrier' is legit as well - it is their
end-user who has been compromised.
Or is simply a professional advertiser studious enough to get all the
dots connected. Dots we lay out for them right here. And they get it
'right enough' that a specific LBL in response to a client complaint is
all that's left, as even their content is crafted to pass.
Meanwhile, layer upon layer of 'features' are piled-onto basic smtp that
focus on progressively less productive minutiae. SPF, DK, DKIM just burn
cycles and pollute headers for the vast majority of traffic, though
their delays and overhead are at least relatively transparent.
Greylisting, OTOH, gets 'in your face' when broadly applied.
I can't see playing the game where one smacks legit arrivals on first
sight just on general principle, then - 'maybe' - is kind enough to
whitelist those who ... actually hadn't set a foot wrong in the first
damned place.
Somebody, somewhere, is larfin' their arse off at all the runnin' in
circles they've got us doing!
Might it be an employment agency? One that places mailadmins into an
expanding need?
Doubtful. I don't see even that sort of gain being had.
Bill
--
韓家標
--
## 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/
