[Mimedefang] Spam through trusted mx relay

[John Rudd]

Kenneth Porter wrote:
> --On Monday, January 29, 2007 9:05 AM -0500 David Koski 
> <dkoski at umich.edu> wrote:
> 
>> Anyone have some thoughts on a better way to detect this type of 
>> forwarded
>> spam and just out right reject just plain bad email from a known good
>> source?
> 
> My practice is to accept and discard spam from a secondary. Rejecting is 
> bad because it causes backscatter when the secondary tries to contact a 
> forged sender with a spam report.
> 

Discarding is bad because you can't prevent false positives, and those 
messages are going to disappear without either the sender or the 
recipient(s) knowing.


Rejecting may cause an intermediate relay to send backscatter, but you 
can't control what some OTHER mail server is or isn't doing.  You can 
only control what your own mail server is or isn't doing.  Therefore, 
you should also not _worry_ about what other mail servers are or aren't 
doing.  It's not within your space of solvable problems.

Further, the highest likelihood is not that you're receiving email from 
an poorly managed intermediary (ie. a server that isn't rejecting spam 
and viruses).  The highest likelihood is that you're receiving the email 
directly from a spambot or virusbot.  Which means: when you reject it, 
nothing else happens.


The choices you have (for both spam and viruses) are:

0) Do nothing (just let the mail flow and be delivered)
1) Mark spam or Clean viruses, and Deliver (let the user deal with it 
via user initiated filters and practices)
2) Quarantine
3) Discard (RFC violation, and generally an irresponsible practice)
4) Bounce (meaning "accept, and then send back) (also irresponsible)
5) Reject


#0 is, anymore, completely irresponsible.

#1 is annoying (since many users wont differentiate between this and 
"doing nothing"), and requires that your back-end mail servers keep up 
with the flow of viruses and spam just as if you were doing nothing 
(worse than if you were doing nothing: you ALSO have to add to it the 
detection process).

#2 requires quite a bit of overhead for the quarantine storage system, 
quarantine reporting mechanism, and the mechanism for allowing users to 
access their quarantine data.  In addition to all of the drawbacks of #1.

#3 and #4 are, for different reasons, irresponsible ... and #4 will get 
you blacklisted (#3, IMO, ought to get you blacklisted for a major RFC 
violation, but it's impossible to detect, so therefore very difficult to 
determine if a site should be blacklisted for it).

That leaves #5.  The cost of #5 is that your detection system has to be 
fast enough to do the detecting during the SMTP session.  Much less 
impact on storage and processes (the drawbacks of #2), isn't an RFC 
violation (#3), and isn't doing all of the things that are wrong with #4.

If you have enough speed to keep up with #5, it is the best of the 5 
options.