[Mimedefang] Cool MIMEDefang/SpamAssassin trick...

[David F. Skoll]

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.

That's cool, although I would clamp it at a reasonable value (30,
say.)  Otherwise some perverse soul might craft a message which gets
as high a score as possible. :-) I wonder what that would be...

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.

I think this has a number of benefits:

- End-users will almost never see spam (SpamAssassin is amazingly accurate)

- Legitimate messages will never be discarded (as long as the human operator
checks the spam trap once a day or so -- most MTA's try sending for
a few days before completely giving up.)

- If lots of people use the system, spam originators and relays will begin
getting a lot of tempfail messages and a lot of full mail spools. :-)

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.

- It wastes bandwidth.

- Some poor sucker has to browse the spam trap. :-)

- 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.

Intereted in hearing others' opinions.

Regards,

David.