[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian



On Sun, Aug 23, 2009 at 02:22:32AM -0700, Steve Langasek wrote:
> Certainly, I see a number of issues on
> <http://home.pages.de/~mandree/qmail-bugs.html> that I would not like to see
> in any package in the archive, not just the delayed-reject bug, and I would
> like to know from Gerrit which of the described bugs are addressed in the
> qmail package before giving it a green light for archive inclusion.

Hmm, doh; apparently this was already addressed in one of the other mails
in this thread that have been waiting for my attention for the past 6
months.

On Tue, Feb 03, 2009 at 08:32:20AM +0000, Gerrit Pape wrote:
>  2.1 I'd suggest not to change that, it's a good compromise between
>  performance and reliability.

  2.1. Bounce message contents are not crash-proof.

  Qmail does not value the contents of a bounce message. Dan documents this
  in a subordinate clause of his qmail reliability FAQ. That means: if your
  qmail is bouncing mail and at the same time, your system crashes, the
  bounce mail contents may be corrupt or incomplete.

This sounds like data loss, which is normally considered a grave bug per
<http://www.debian.org/Bugs/Developer>.  Do people disagree that this is a
grave bug?  If you think it's a grave bug, do you think it should be a
blocker for archive inclusion?

>  2.2 qmail's MDA qmail-local doesn't override files on name collisions,
>  but stops, and retries later.  If there's really mail loss, some MUA
>  misses the required sanity checks.

This is one that I think should have been a blocker if it were present; glad
to hear it's addressed.

>  2.3 I fail to see the impact.

Sounds like it would cause bugs in mail routing by not knowing whether an
address is local.  Not something I think is a blocker.

There's also this one:

  4.12. qmail's sendmail -f is not compatible with sendmail.

  qmail's sendmail wrapper does not implement -f properly, in that it does
  not set the default From: address for messages lacking one, but only
  setting the envelope. This differs from original sendmail behavior and
  breaks some applications.

This behavior contradicts the LSB; from
<http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/baselib-sendmail-1.html>:

  -f name	 	

    explicitly set the envelope sender address for incoming mail. If there
    is no From: header, the address specified in the From: header will also
    be set.

    If the user running sendmail is not sufficiently trusted, then the
    actual sender shall be indicated in the message.

This is not a blocker for the package's inclusion in the archive, but it
must then declare that it Conflicts: lsb-core so that any LSB packages users
wish to install don't silently get an incompatible sendmail implementation. 
(The nullmailer package already in the archive does the same thing; except
that it conflicts with 'lsb', when it should conflict instead with the core
lsb package since sendmail's behavior is part of the core specification.)

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: