Re: [exim] two stage virus scan

On Tue, Jun 20, 2006 at 08:22:46AM -0400, Marc Sherman wrote:
> Chris Lightfoot wrote:
> >
> > The difficulty here is that in the current email
> > architecture the only person who can detect whether a
> > bounce is valid is the (alleged) sender. A third-party
> > mail server *cannot* determine whether a given bounce is
> > valid or not. Dropping delivery error notifications on the
> > floor based on some heuristic is incorrect; refusing mail
> > transactions from hosts purely because they correctly
> > process delivery error notifications is idiotic. (I hope,
> > by the way, that you fully inform your users that you are
> > programming your mail server to discard information about
> > whether their mail got through or not.)
>
> You're just plain wrong here, Chris. Once you've accepted a message,
> it's your responsibility. If you choose to accept messages and then scan
> for viruses after acceptance, the only responsible option available is
> to freeze/quarantine the virus on your own system, and have your own
> staff (either the recipient or someone on your postmaster staff) review
> the quarantine manually. As you point out, simply dropping them on the
> floor without notification to the sender is unreasonable, but bouncing a
> virus (or a virus notification) to an unverified and very likely forged
> sender is just as unreasonable, if not more so.

It is obviously true that a mail server should do its best
to determine whether or not it can accept a mail at SMTP
time. But sometimes it is not possible to do this and in
those cases it is necessary to generate a bounce (the
alternative is to give in to unreliability). Generally it
is not possible for an arbitrary third party to determine
whether this is a valid bounce (i.e., resulted from an
email which the recipient of the bounce sent themselves)
or an invalid one (i.e., which resulted from address
forgery). On the other hand, it is trivial for a recipient
to distinguish valid from invalid bounces, and discard the
invalid ones.

Therefore, it is obvious that the correct course of action
is to pass on the bounce, rather than trying to guess
whether it is valid or not. Such guessing would risk
discarding a valid bounce, which is inappropriate -- if a
mail was undeliverable, you must do all you can to inform
the sender. Of course, the sender's ISP may have decided
-- perhaps even with the consent of the sender! -- that
they're going to discard all bounces, whether valid or
invalid, but there's nothing you can do about that.

But we must also consider the modern practice of
tabulating hosts which send bounces in a `blacklist', and
then refusing or discarding any mail at all from them.
This is foolish, because it ensures that users will not
receive valid bounces -- or any other mail -- from those
servers; nevertheless it is commonplace now, hence the
advice of emitting bounces only from a specific IP address
allocated for this purpose (this is actually the advice of
one of the blacklist maintainers, iirc). Of course, this
does nothing to make email any more reliable (because
subscribers to the blacklist will still be preventing
valid bounces from reaching their users), but it does mean
that the blame for its unreliability rests with the users
of the blacklist (they could decide to behave sensibly if
they wanted to) and not with the host which gets stuck
with an undeliverable mail (and which would otherwise have
to guess whether it should bounce it and risk being
blacklisted, or drop it on the floor and contribute to the
unreliability problem).


(There are of course other types of blacklists, for
instance those which record hosts alleged to have sent
undesirable non-bounce mail. Enthusiastic users of these
are typically found to have oversimplified the problem,
but that is a separate issue.)

--
``I shall send a big blue incorruptible policeman to lock you
up and the only `monumental' work Mr. Scherman is likely to
perform is breaking stones at Dartmoor.''
(Evelyn Waugh, to Life magazine, prohibiting them from reprinting his work)