Re: [AMaViS-user] W32/Bagle-A

[Robert L. <rj...@re...>]

At 17:52 2004/01/20, Alex Satrapa wrote:
>Robert LeBlanc wrote:
>
>I can only reject the email, and leave it up to the sending MTA to handle 
>the rejection properly.
>
>>... Since amavis is smart enough not to include the virus in the DSN, the 
>>notice the sender receives is at least "clean".
>
>But the wrong person gets it.
>
>At least when one of my clients tries sending email through my SMTP 
>server, they'll get the rejection notice immediately. The mail won't go 
>anywhere, they won't get any bounce, they just get a message from their 
>MUA saying that the message was rejected.

This assumes that your MTA "handles the rejection [from amavis] properly", 
of course.  MTAs know nothing about viruses (or spam for that matter), so 
they can't do the rejection themselves on this basis.  When clients send 
mail through your MTA, your MTA relays that mail to amavis, which does the 
content-checking.  If amavis finds a virus and uses D_REJECT, the 
responsibility falls back to your MTA to decide what to do.  When MTAs 
receive a permanent failure SMTP error (i.e. 5xx), they try to be helpful 
by generating DSNs that include the full original mail, to send back to the 
sender, explaining the rejection.  Your client would then get the virus 
sent back to him in the DSN.

This is harmless (quite helpful, actually) when the sender happens to have 
an old-style virus, of course, but with the "viruses that fake sender 
addresses" this is a distribution method.  Consider that your user has one 
of these viruses on his machine and it starts spewing out copies of itself 
through your mail server, all with fake sender addresses.  When your MTA 
sends out its DSNs to those fake addresses, those DSNs will contain the virus.

If you'd used D_BOUNCE instead, the DSNs would be issued by amavis (which 
is virus-aware) rather than your MTA (which isn't), so the mail going to 
those fake senders would be virus-free.

My point is that your idea of "reject at the MTA" doesn't work as such, 
because the MTA does not have a virus scanner embedded in its own 
logic.  The rejection takes place at the content-filtering stage (i.e. 
amavis), so the rejection is handed to the MTA by amavis, rather than from 
your MTA to the client.  Your MTA will still produce a DSN and helpfully 
send back the original mail--that's what SMTP dictates that it *must* 
do.  You're better off using D_BOUNCE and letting amavis issue its own DSN, 
so that at least you won't be spreading the virus itself any 
further.  *Both* methods generate spam-by-proxy, but one of them also 
spreads viruses.

The closest thing to an "ideal" solution, in my (admittedly biased) 
opinion, is what I refer to as the "discard safely" policy--D_DISCARD items 
like these after quarantining them--provided that you have a quarantine 
management system (e.g. Maia Mailguard) that lets users access these 
quarantined items.  No DSNs get sent out, as the mail is effectively 
"accepted" (into quarantine), and the local recipients have access to this 
special mailbox to retrieve anything they want to keep, so there's no 
*need* for a DSN--the mail was, for all intents and purposes, sucessfully 
"delivered" to the recipients.


Robert LeBlanc
Renaissoft, Inc.