[Mimedefang] Spam through trusted mx relay

[John Rudd]

Kees Theunissen wrote:
> On Mon, 29 Jan 2007, John Rudd wrote:
> 
>> 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
>>
> 
> [ ... explanation why options 0 to 4 are a BadThing(tm) to do ]
> 
>> 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.
> 
> Yes in general I would agree with this. But David Koski was talking
> about a MX host relaying messages for his domain.


I hadn't looked back to the OP's scenario ... sorry.


> If you want or need to use a secundairy MX host you better choose
> a host that can do all filtering you need. You're too late te reject
> a message if it has been accepted by your MX host.

Yes, I would agree ... your non-primary MX hosts need to be rejecting 
with the same criteria as your primary host.


In my production environment, back-line trusts the front-line, and visa 
versa.  So, if something gets past the front-line, it gets passed 
through the back-line into the user's mailbox.  In essence, I treat the 
collection of back-line and front-line servers as 1 big box -- once a 
message is admitted into this big box, it's admitted.