[Top] [All Lists]

Re: [Asrg] 0. General

2003-10-23 10:17:10
At 4:07 PM -0400 2003/10/22, David Maxwell wrote:
So, connections from nameless IPs probably deserve to be weighted as
'spam-likely' in your consent decision. Perhaps even 'spam, guaranteed'.

      That's fine, but keep in mind that this has collateral damage 

It's my choice to accept those consequences - it's _my_ consent

      Use DRIP (or DRIP-like techniques) as a whitelist, and that can 
be abused, too -- Plenty of spammers are perfectly happy to 
authenticate in whatever way you want, and will make sure that their 
reverse DNS fully matches, etc... just to get their mail through. 

That's not an abuse of DRIP. DRIP provides a layer upon which I can add
a white/grey/blacklist by domain. Without DRIP (or RMX, etc), I cannot
whitelist by domain, since spammers can forge spam claiming to be from
one of the domains I whitelist.

Then there are the virus/spammers who use victim machines distributed 
around the world, most of whom probably are properly configured to 
use outbound mail relays that are likewise correctly configured.

Many of the viruses forge email source. If they didn't, I could easily
contact the sender and tell them to cleanup their machine.

That design decision was made before the current situation came into
being. Now, my spamassassin installation spends far more time doing
content inspection on spam messages than the 'too much time' it would
take to validate the provided hostname.

      Then your spamassassin configuration is not correctly configured. 
You shouldn't be using it that way unless you can make sure that you 
can conform to the same kinds of situations and response times as 
were anticipated when the RFC was written.

I'm not rejecting the mails in the SMTP phase - so the RFC specs are not
relevant - however, the fact that I cannot implement
white/grey/blacklists leaves content inspection as the only method to
identify spam. That 'guesswork' takes a lot of CPU time, and gives me a
very non-deterministic answer anyway.

The network environment has changed, the assumptions about overhead need
to be re-evaluated.

      Re-writing the RFC is a different matter, something which I 
believe we are also participating in.  However, until the RFC is 
re-written and gotten to at least the "Proposed Standard" stage, you 
should not be knowingly in violation of it.

I'm not violating it - I'm discussing changing it.


Asrg mailing list

<Prev in Thread] Current Thread [Next in Thread>