Re: [exim] Email DNS Issue

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: W B Hacker
Data:  
Para: exim users
Assunto: Re: [exim] Email DNS Issue
Craig Jackson wrote:
>
>
>> -----Original Message-----
>> From: exim-users-bounces@???
>> [mailto:exim-users-bounces@exim.org] On Behalf Of W B Hacker
>> Sent: Friday, March 14, 2008 1:48 PM
>> To: exim users
>> Subject: Re: [exim] Email DNS Issue
>>
>> Matt wrote:
>
> snipped
>
>> Better yet - use more consistently predictable tools and retire that
>> test altogether as unpredictable at best.
>>
>
> I understand what you're saying, but I don't wholly agree because I
> notice that much of the spam we get (even the junkiest lowliest of spam)
> passes this verify test and I figure it takes some resources and effort
> to set up their servers to validate the sender. So it gives spammers one
> more hoop to jump through. Just because they jump through the hoop,
> doesn't mean we shouldn't continue to make them jump through it. But I
> never reject based on a fail, only add a point or two to Spamassassin
> score.
>
> Craig
>


Flawed logic. Heavily so. (the 'hoops')

We aren't dealing with human beings - or even animals - that get tired,
exhibit learning behaviour - and go away.

We are dealing with billions of infected WinBoxen that do NOT get tired,
learn only what their botmaster's program into them from analyzing their
'hit' statistics, not their 'fail' statistics, (they must have such..),
and do NOT 'go away'.

Any form of baiting them, playing with them, honeypot or tarpitting them
- trying to make them jump through hoops - is counterproductive.

All it does is eat more CPU cycles and bandwidth - both your own, the
victim's, and everyone in between.

*stolen* resources, of zero cost to the botmaster.

Ultimately adding to Global Warming, if you will.

What we want is the earliest possible disposal and least risk of
blocking 'good' mail - two circumstances that pull in opposite directions.

But if you could have one - and ONLY ONE tool - lack of a proper PTR RR
is the single most effective one, and with the least risk of improper
rejection.

'False Positives' - Not.

Badly configured senders - sadly.


Bill