[Mimedefang] Cool MIMEDefang/SpamAssassin trick...

[Nels Lindquist]

On 22 Feb 2002 at 16:07, David F. Skoll wrote:

> On Fri, 22 Feb 2002, Mark Roedel wrote:
> 
> > What I wound up doing instead was to create an X-Spam-Level header that
> > contains a string of *'s equivalent to the integer part of the
> > SpamAssassin score.

Neat!  Very easy for individuals to control their own threshold.
 
> I have an idea for a very nice anti-spam architecture.  I want to add
> code which, when a message is considered spam, sends an SMTP temporary-failure
> code to the sender:
> 
> 	451 4.7.2 Message appears to be spam; awaiting human verification
> 
> The SHA1 hash of the first 100 lines of the message body is used as a key
> into a database (could be a real database; could be file/directory based)
> We store the relay IP address, relay name, message subject and first few kB
> of the message in the database.  A cron job clears out old entries
> periodically.
> 
> Then we have a nice Web-based front-end which lets the admin glance over
> the SPAM of the day and either:
> 
> - Reject the message as SPAM.  It will be permanently rejected with a 551
> message on the next attempt.
> 
> - Blacklist the relay host altogether (optionally submitting it to
> ORBZ/ORDB/whatever)
> 
> - Whitelist the relay host so it is never checked for spam.
> 
> - Accept the message as OK.  It will be allowed through on the next attempt.

This kind of functionality is very, very similar to what SpamCop 
offers as a commercial service.  IOW, there'd definitely be demand 
for it. :-)

Come to think of it, integration with SpamCop for reporting purposes 
wouldn't necessarily be a bad idea...
 
> It has one very serious drawback and a few minor ones:
> 
> - Having a system administrator glance through the spam trap could lead
> to serious privacy concerns.  So this system is probably inappropriate
> for an ISP, but may be acceptable for a corporation.

Even at the ISP level, there is likely a class of customer (eg, those 
who pay extra for content filters) who would happily make the 
tradeoff if they can be sure their kids aren't going to get porn spam 
in their mailboxes.  Of course, one would need to be able to control 
this at the individual user level to make this work.  There might 
even be ISPs interested in purchasing this kind of technology, 
especially in light of the U.S. Government's recent rumblings to the 
effect of "clean it up soon or we'll legislate something."

Another mitigating factor is that false positive mail tends to be 
fairly generic in nature (mailing list traffic, solicited sales 
information and the like), which sidesteps the privacy issue 
somewhat.  Is this true of other peoples' experience?
 
> - It wastes bandwidth.

"Waste" is such a *negative* word.  It *utilizes* bandwidth, which 
may or may not be a problem depending on your situation. :-)
 
> - Some poor sucker has to browse the spam trap. :-)

True.  However, I agree with Mark's assessment that at a local site 
level you'd probably have a "reject out of hand" threshold set 
somewhat higher than the "spam trap" threshold--you'd never see 
messages above a certain score, and that'd cut down on the volume 
substantially.
 
> - It could have security implications -- someone could send lots of
> slightly-different spam-like messages to cause the database to grow
> enormously.  This could be mitigated by limiting the number of messages
> per SMTP relay which are allowed to be in the database.

You could also accumulate a "relay score" -- keep a separate table 
for mail relays with an accumulating "number of spammish messages" 
field. Once a certain threshold is reached (over a certain time 
period, maybe?), start rejecting mail from that relay.
Nels Lindquist <*>
----
Quidquid latine dictum sit altum viditur.

Whatever is said in Latin, sounds profound.