Re: tlug: A myriad of mailers

[Rex Walters <rex@example.com>]

>>>>> Chris Sekiya writes:  (on 10 Mar 99)

> qmail didn't mean enough to me to fix.  I was looking for a reason to
> stick with sendmail anyway.

Snort.

At least you're up front with you prejudices, but I must say I find your
apocryphal story somewhat suspect.  

That qmail-smtpd used to exit (are you sure it was a segfault?) when fed
headers in gross violation of RFC 821 was by design (behavior since
modified).  Quoting from Bernstein's "SECURITY" file in the qmail
distribution:

    5. Don't parse.

    I have discovered that there are two types of command interfaces in the
    world of computing: good interfaces and user interfaces.

    The essence of user interfaces is _parsing_---converting an unstructured
    sequence of commands, in a format usually determined more by psychology
    than by solid engineering, into structured data.

    When another programmer wants to talk to a user interface, he has to
    _quote_: convert his structured data into an unstructured sequence of
    commands that the parser will, he hopes, convert back into the original
    structured data.

    This situation is a recipe for disaster. The parser often has bugs: it
    fails to handle some inputs according to the documented interface. The
    quoter often has bugs: it produces outputs that do not have the right
    meaning. Only on rare joyous occasions does it happen that the parser
    and the quoter both misinterpret the interface in the same way.

    When the original data is controlled by a malicious user, many of these
    bugs translate into security holes. Some examples: the Linux login
    -froot security hole; the classic find | xargs rm security hole; the
    Majordomo injection security hole. Even a simple parser like getopt is
    complicated enough for people to screw up the quoting.

    In qmail, all the internal file structures are incredibly simple: text0
    lines beginning with single-character commands. (text0 format means that
    lines are separated by a 0 byte instead of line feed.) The program-level
    interfaces don't take options.

    All the complexity of parsing RFC 822 address lists and rewriting
    headers is in the qmail-inject program, which runs without privileges
    and is essentially part of the UA.

SMTP is *not* a user interface.  Programs talking to programs are
expected to follow protocol.  When garbage is generated, guessing what
was intended is a never ending game.  Sendmail plays this game regularly
(which explains the astronomic revision numbers).  Qmail only does it
under duress (qmail-1.03 *will* accept from broken mailers that don't
provide the angle brackets in "from:" declarations -- which actually
surpised me when I just tried it).  But ONLY when it can't possibly
cause data loss or security problems (witness CRLF and bare linefeeds).

Qmail 1.03, btw, was released on June 15th, 1998, which was well over 6
months ago.  It's much easier to keep up with qmail releases than it is
to keep up with sendmail.  Looking for excuses to stick with what you
have by picking holes in old versions of software is pretty lame, IMHO.

Now defensive programming and the robustness principle certainly apply,
but Dan Bernstein has made no bones about explicitly *not* being liberal
in what he accepts with qmail (for reasons I'll leave to another thread
-- see his documents on design at http://pobox.com/~djb/djb.html for
details).  If he was segfault'ing then there was certainly a bug (you
did report the problem didn't you?) if he merely aborted, as your "from
memory" telnet session could just as easily imply, then qmail-smptd may
have simply exited -- which I would consider a valid response to being
fed garbage.

Most reasonable, perhaps, is simply to drop the connection rather than
exiting.  Personally, I run qmail-smtpd under tcpserver (which I find
more reliable than even xinetd) but as long as you use some kind of
meta-server like inetd, it makes little practical difference if the
program simply exits when fed bad data.

Some have tried to use the fact that sendmail accepts such malformed
smtp commands as an argument that qmail should as well.  The argument
hasn't had much success.  The most succinct reply I saw on the qmail
mailing list was from Louis Theran in a thread titled "Invalid SMTP
Header"
(http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/03/threads.html):

    > I think that's sufficiently broken that "liberal in what you accept"
    > doesn't cover it ;-). "MAIL bob@example.com" should be accepted though.

    I take it that you are willing to enumerate all the possibilities and
    tell us which ones are ok and which are "sufficiently broken."  Maybe
    you could write an RFC about this.  That way there would at least be
    some standard for broken behavior and what to do about it.  ;-}

    What ISP Power is doing is not legal SMTP.  It has never been legal
    SMTP.  ISP Power is broken, not qmail-smtpd.

Although, seeing your bias toward sendmail, perhaps you feel that
sendmail should be considered the standard for broken behaviour?

Regards,
-- 
Rex
-------------------------------------------------------------------
Next Nomikai: March 19 (Fri), 19:30  Tengu TokyoEkiMae 03-3275-3691
Next Technical Meeting: April 10 (Sat), 12:30   place: Temple Univ.
-------------------------------------------------------------------
more info: http://tlug.linux.or.jp                     Sponsor: PHT