Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Steve Langasek <vorlon@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: