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) -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
