Re: [exim] Exim outgoing emails throttling

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
--
韓家標