[ On Thursday, February 20, 2003 at 16:08:54 (-0500), James P. Roberts wrote: ]
> Subject: Re: [Exim] bouncing viruses
>
> As I understand the discussion, my summary is as follows:
>
> IF you choose to scan for viruses, AND you detect one, THEN:
> The physically possible actions (without regard to good/bad) are:
> (a) bounce it, (b) accept and deliver, (c) accept and "de-fang",
> (d) accept and bit-bucket, or (e) reject at SMTP time (if you can
> scan early and fast enough).
Close enough... [option (c) has two sub-options, one being the actual
disabling of the worm or virus, and the other being just tagging and/or
re-routing it so that it can be treated with rubber gloves and tongs or
their virtual equivalent]
> I gather that "(a) bounce it" is not a generally acceptable idea,
> even though it is possible to do, because there are negative
> side affects, the main ones being (1) inability to bounce due to
> forged sender addresses, and (2) sending bounces to innocent
> 3rd parties that are victims of forged addresses.
You (and others) seem to think there's some diference between (1) and
(2), but in fact there is none, or at least none that you can know.
From the SMTP server's point of view once some determination has been
made that the content of the message may be infected with a virus or
contain a worm then everything about the message _MUST_ be treated with
even more distrust than one would normally treat such data, including
the envelope sender address. The only thing you can know with relative
certainty is the IP address of the client-SMTP you are, or have just
been, connected with.
> It seems obvious that (e) would be the preferred solution, in
> cases where the server has the resources to do so.
No, it's not so obvious that rejecting at SMTP-time is the preferred
solution. It's not just a question of resources per se, and where you
choose to deploy them, but also about the knowledge you might have
about, and the trust you put in, the client-host's SMTP protocol
implementation, as well as the knowledge you have (or do not have) about
your own user base.
Assuming the client-SMTP was a remote (and thus untrusted) host then the
only really obvious (and thus preferred) solution is to accept the
message, identify it as containing questionable content, and ask the
intended recipient whether to deliver (perhaps with de-fanging or
tagging) or delete it.
Maybe if the client-SMTP is actually a locally trusted host then you'll
want to do something completely different....
> However,
> there may be a problem with certain virus senders ignoring the
> 5xx reject during, or at the end of, DATA.
At the end-of-DATA _only_ please. An SMTP server MUST NOT try to send
any response until the end-of-DATA (".") has been received. Well, I
suppose it could try, but it had damn well better keep reading until
end-of-DATA! If it doesn't and if the client-SMTP isn't the virus or
worm itself then that message won't go away (until the client-SMTP gives
up some days later) and nobody on the sending side can possibly ever
know why it won't either go through or bounce. The sender can only
complain that the receiving-SMTP is completely broken and useless. I'll
bet some MTAs will effectively stop sending all messages to a site which
misbehaves so badly.
(Of course if the client-SMTP is in fact the virus or worm itself then
it may still keep hitting on your server no matter what you do :-)
> TANMB (There Are No Magic Bullets).
Well, eliminating and/or fixing broken MUAs that your mailer delivers to
and which are vulnerable to remote exploits would be one definite magic
bullet right into the bulls-eye of the problem.....
> By far, the biggest decision you can make, is whether to scan for
> viruses at the MTA level at all. If you choose not to, all the other
> questions become moot. If you choose to, then you must also
> make these additional decisions, and live with the consequences
> in your own environment.
I certainly like, and agree with, that part!
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
