Re: [exim] DKIM

Mike Cardwell wrote:
> W B Hacker wrote:
>
>>> The fault is with the rfc. Tis to vague on various points. Such as third party senders.
>>> To my mind DKIM will go the same way as SPF. There needs to be a better policy introduced for controlling spam.
>>> The death penalty comes to mind;-)
>>>
>>> David
>> + rDNS fail (hard score)
>>
>> + dynamic-IP RBL hit (hard score)
>>
>> + HELO not matching to FQDN of connected IP (softer score)
>>
>> + 15s delay (zombots are impatient)
>>
>> + Local & remote BL of hte hard-core
>>
>> - a relatively modest White List ..
>>
>> *IS* near-as-dammit a 'death penalty' for spam.
>>
>> How does an infected WinBox get itself past those?
>>
>> Cheap, cheerful, no need for greylisting, light ClamAV, SA and similar
>> resource loads.
>>
>> Enough of us do the basics, there is no need for SPF or DKIM, and sloppy
>> DNS's entries of legit MTA's will get cleaned up 'Real Soon Now'.
>>
>> But it will *never* happen so long as we take the obsolete 'be generous
>> with what you accept' road.
>>
>> Zombots rely on that ...
>>
>> Starve 'em!
>
> Many of your solutions work for you purely because few other people use
> them.

I think that should say '..few have found easy ways to defeat them'.

*Many* use forward/reverse lookup, seek proper DNS records, scrutinize
HELO for obvious forgery, et al.

Overall, be it the tools I prefer, or 'all of the above' it seems to be
working.

That the criminal gangs appear to have shifted emphasis to non-mail
avenues and malicious/compromised web sites tells me that they are
finding diminishing returns from email as an avenue of attack.

Regardless of specific tools, as a community, MailAdmins have become
more aware - and far less forgiving.

> The bulk of spam is easy to block. It's the less obvious stuff
> that people spend 99% of their effort trying to come up with solutions
> to block.

Also true. I have more than once mentioned ~/configure files of 2,000
and 3,000 lines... There are a great many convoluted acl tests there.

But the point has been that most are only rarely 'triggered', and that
more often than not to reduce 'false positives'.

Either way - one of the objectives is to reduce the percentage where we
need to call on the more resource-intensive 'externals', such as ClamAV
or SA.

The combination buys us back the resources to DO those complex tests
well and still keep overall server load within capability.

>
> I still don't get this argument:
>
> "Here's a mechanism to allow you to sign emails that come from your
> domain so other systems can detect spoof attempts automatically"
>
> "But spam exists. And that mechanism doesn't stop spam. Therefore it has
> no use."
>
> Mike
>

I'm not advocating that we abandon DKIM et al - just put them in their
proper light.

Minor refinements - not 'ultimate solutions'.

Too many - and not just 'newbies' - seem to fixate on each new toolset
of that sort as it crosses the stage (SpamAsssassin, tmda, greylisting,
spf, dummy mx honeypots, complex REGEXP, DK, DKIM), AND NOT bother to do
the 'basics' also.

'Flavor of the year' so to speak.

Spammers must love it when we get off-track, chase edge-cases, and
forget to firmly implement the 'basics' provided in the earliest of smtp
RFC's.

JM2CW,

Bill Hacker