[Asrg] where the message originated

[Alessandro Vesely]

Rich Kulawiec wrote:
>> Correct. The anti-virus filter should just swallow the message with no
>> complains nor notices. I don't know what RFC blesses that behavior,
>> though.
> 
> Incorrect.  The receiving MTA should reject with an appropriate error
> message.  While it's much more likely that a malware filter will generate
> a FN than a FP, it's still possible, and an error message will be helpful
> in tracking down such situations.

Rejecting has been my first approach when I first installed an 
avfilter. When I realized the number of infections I was causing that 
way, I started to drop rather than reject. Since 2001, I've had a 
couple of FNs and no FP that I'm aware of. (I'm talking specific virus 
detection, not heuristic anti-malware filters.)

> It might -- and I may be over-optimistic
> here -- also help notify the originating site that it has a problem,
> if they're paying attention to their own logs, and if they're not
> doing it on purpose.

I have in front of me the latest instance of W32/Netsky-D I received. 
(I still dump viral messages in a system folder not readable by 
users.) It is a bounce, so in this case I could have rejected it with 
less worries. What reaction would the remote postmaster have had? I 
have difficulties in estimating the worthiness of amending my software 
so as to reject rather than drop in case the envelope sender is void.

For regular messages, rejection causes viruses to be delivered to end 
users, which is wrong because it spreads them. I don't think virus 
writers spread their original copies via their own MTAs; that is to 
say, IMHO MTAs are not doing it on purpose. However, I assume the 
remote MTA has no avfilter, otherwise it wouldn't relay viruses. Most 
probably, on rejection it will attempt to deliver a bounce. Failure to 
do so would result in the same net effect as dropping; so let's 
consider only infected bounces that are successfully delivered to end 
users: what are the chances that one of them results in an alert 
rather than yet another infection? Let's over-optimistically estimate 
we can get 1 alert for every 10 new infections. I don't deem that is 
anywhere near a desirable outcome. If I were a judge I would condemn 
postmasters wittingly doing so.

> The more general principle here is that mail should never disappear into
> a black hole.

Agreed. A virus should be caught right after the client submits it. 
Reject vs. drop has a different meaning in this case: diagnosing an 
infected client should sound all available whistles and bells in 
either case.

For relayed infected stuff, feedback loops may be a valid alternative 
to the black hole. However, zombie detection is not a topic restricted 
to email management.