Steve Langasek <vor...@debian.org> writes: > On Wed, Aug 26, 2009 at 09:18:03PM -0700, Russ Allbery wrote:
>> Well, that's a specification for multipart/report, which qmail doesn't >> attempt to comply with. (Neither do many other MTAs, although more do >> now than used to.) >> At a basic SMTP protocol level, a lot of mail servers no longer return >> bounces at *all*, or at least throttle them heavily, because of the >> abuse problems. They're increasingly useless. > The backscatter problem certainly gives a compelling reason to try to > reject at SMTP and avoid the need to bounce, but once a message of mine > has been accepted by a remote server, if it fails to be delivered I do > expect a notification. Servers that refuse to do this are in violation > of the protocol, and undermine a core feature of SMTP (reliability). The inbound mail servers at stanford.edu intentionally accept and silently drop messages that we detect as being viruses or very high-probability spam. If we generate a bounce or allow the remote server to generate a bounce, 99 times out of 100 that mail will end up going to some innocent third party and may further spread malicious content. We've tried various different approaches for this over the years, and we're firmly convinced that this is the right decision for many different reasons. I'm afraid the days when reliability was a core SMTP feature are long, long past, for both this and many other reasons. >> It's been a long time since I ran qmail, but as I recall, and according >> to the specification, the bounce includes the entire original message. >> The reliability note is just djb doing the full disclosure thing that >> he sometimes does. The point is that qmail can, in some circumstances, >> lose part of the bounce message if the mail system crashes at exactly >> the wrong point. Seems like a rather minor problem to me. > If it loses enough of the bounce message then the DSN is potentially > rendered useless. I think that's a "data loss" bug, just as I think a > package sending your existing files off into la-la land on an OOD > condition is a data loss bug. I understand where you're coming from, and I recognize that you say bug rather than RC bug. I don't object to calling it a bug, but were I the qmail maintainer, I'd make it severity: normal at most, and more likely minor. In terms of practical impact on our users, there just aren't enough people or enough data possibly affected here. I'm certain the archive is full of programs that, if you kill them at exactly the wrong time, will lose more significant data more frequently than this edge case. One can start with any program that doesn't auto-save data files. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
