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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg