Re: Request for "maildir" support

[eichin@cygnus.com]

-----BEGIN PGP SIGNED MESSAGE-----

Date: 4 Mar 1996

There are *so* many misconceptions (not just disagreements of opinion,
which I could easily abide, but factual errors) that I feel compelled
to respond, as a qmail beta tester, and a security professional. (I'd
actually like to see maildir support in ding, even though I'll most
likely continue to only use movemail-based POP support -- it would be
nice to have at least one *reliable* non-pop delivery mechanism,
regardless of what mailer implements it.)

> So much for standards :).
When standards are broken, it's long past time to develop new ones :-)

>I would suggest someone inform this person about Eric Allman's v8
>sendmail, 8.7, which is about as secure and reliable as you can get

Yep. Unfortunately, "secure as you can get", with sendmail, is "not
at all." Did you see last weeks "dns spoofing" vulnerability problem?
It's yet another in a long running series of the kind of problem you
have when you *design* a program to have back doors (yes, I mean
that. The sendmail "DEBUG" mode exploited by the Morris Internet worm,
back in 1988, was a *deliberate* inclusion, because Allman couldn't
get root access to the machine he was maintaining sendmail on
originally... and the feature didn't get completely rooted out until
years later...)

> Ahem.  This is bullshit.  NFS is infamous for it's inability to do
> exactly this, and no matter what you do to get around it you will still

Turns out that creating multics-style timestamp-based names which are
unique in and of themselves works fine - you don't have collisions
because you're *never* working on the same file. It *is* possible; you
just have to be more clever than people have in the past...

> a modicum of clues running large mailing lists uses a caching MTA like
> v8 sendmail with bulk_mailer, which I have found to work exceptionally

Well, no. vger.rutgers.edu is running zmailer, because sendmail just
couldn't handle the linux-* mailing lists, even with a multi-cpu
machine with 256M of RAM... David Miller has to work quite closely
with the author of zmailer to get even that to work, but sendmail
isn't even in the running.

> Users handle their own mailing lists != "simple", from my experience
> both as a Majordomo list and server administrator.

Perhaps that's because exsisting techniques are primitive? He really
has come up with some quite clever things -- we may need some more
practice with them, but what he's got does work.

> v8 sendmail does it internally.  All you need to do is configure a
> couple of options in sendmail.cf

That *alone* is a condemnation :-) But it also means that you're stuck
with sendmail's precise scheduling techniques; you don't have nearly
the control that you get with a modern inetd and qmail.

> And then there's simple fact that in a "unified" system if one little
> thing breaks the whole thing goes down, whereas in an "modular" system

You mean the way that if you make a single typo in your sendmail.cf
everything goes down? :-) qmail *is* quite modular. From your
comments, I think you'd be surprised with what you'd find by looking
at it.

> This whole thing reminds me a lot of SMail and how it absolutely failed
> in many ways to "fix" perceived "problems" in sendmail.  Not that I am

Smail didn't even handle *obvious* things like MX records, at least at
first. qmail is written by someone who reads and has written RFC's...

> with an MTA that is written and maintained by someone I know knows to
> write and support a reliable, secure MTA.

I wonder who that could be. Sure isn't Eric Allman :->

If you'd like to know more, you could join the qmail beta test; the
release actually includes a number of detailed explanations of the
issues involved.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4beta, an Emacs/PGP interface

iQCVAwUBMTsgl1y/7Dlmzom3AQHi6gP7BNtPsxZEN9Gw4j90VC/LChBDcg/dJrXF
H6kUl8wbfrgFAGQQixyd9YZpNDTiLZ9M9DP+NceO56kcFnxqeLj1LCbi3v7+5Chf
cyqdRo+M6BI3DcNecGHSt/2U7MhAxME6o89XHcHaxmgU89Bc2xiy5l30iM9akDP5
jGXMwm6ix3w=
=fpfr
-----END PGP SIGNATURE-----