Re: How about maildir support?

[Matthew Hawkins <matt mail goldweb com au>]

On Wed, 17 Jun 1998, spacey@30minutes.netcreations.com wrote:

> [Sorry to respond so late, I'm behind on my mail]

<AOL> Me too </AOL>

> Mostly I wanted to clear up your misconceptions.  Like the idea that
> complete documentation is the most important part of the program.
> While it's nice, I don't think that anyone should have to pay for a
> book that's thicker then a bible just to be able to send mail,
> especially when many other mailers have proven that it's just not
> necessary.

Who said anything about paying for a book?  Programs are written to
documentation, not vice-versa.  When a program does not perform to what
is written in its documentation, I consider the program to be broken.
Qmail 1.01 is such a program.

> > Qmail's documentation is incomplete & quite inaccurate in parts,
> I've used qmail for 2 years now, and there has yet to be an inaccuracy
> that I've run into.  Please demonstrate an inaccuracy that isn't the
> result of a mis-reading.

After denying a particular site from sending mail as per the documentation
in Qmail 1.01, said site was still able to connect and send mail.  So much
for anti-spam.  After configuring a virtual host as per the documentation,
sending mail to that host resulted in a bounce saying that, more or less,
virtual hosting did not work.
I spent about 12 hours total trying to get things to work.  I considered
that it may have been a misreading on my part.  I asked around and consulted
others.  Everyone agreed that what I had done was correct according to the
documentation, and another mentioned having similar problems and resorting
to sendmail.

> > many features like virtual hosting and anti-spam do not work,
> Anti-relaying measures work very well, and are on by default.  Virtual
> hosting works, and works easily and more configurably then sendmail's

Adding the domain into the CW ruleset db is a hell of a lot easier than
the convoluted qmail process of editing various files scattered in a 
disorganised fashion across the filesystem.

> (i.e. you can forward e-mail to a directory owned by your vhost
> customer, and let them add and remove their own users, without needing
> special privliges).

I would consider this a security problem.  I can see how the "feature"
could be useful for an extremely large virtual hosting site, however I for
one would not like any joe user to be able to reconfigure my mail system.

> > it's not actively maintained (sorry, I can't count a new release
> > 15 months later "active") 
> 1.03 is out, about 1 month after 1.02.  However, there was only 1
> glaring bug in 1.02, and it didn't affect mail delivery.  New features
> and changes were *tested* before release, you see.

Interesting, no mention of the large gap between the quite obviously broken
1.01 and 1.02 (which I have not tried as I required a working mail system).

> > and the fallback defence "it's more
> > secure than sendmail" is getting rather old and worn.
> However true it is, eh?  Never mind that it's easier to configure, the
> anti-relaying measures have worked for 2 years now, at least one large
> site (estimated .5 million deliveries/day) running 0.7x (or so) hasn't
> had to upgrade from that early beta stage because it's been solid,
> fast, and secure for that time period?

Well it's not true, it's not easier to configure, and one success story
versus two unsuccessful stories still tips the scales in my favour.
BTW, I forgot to mention, I got fed up after the 12 hours of attempting to
get Qmail to work to how its documentation says its supposed to, and in
half an hour including compile time on a 486 I had BSD sendmail doing 
everything necessary, and actually working fully tested.

> It doesn't necessarily have to do with the MTA, it has to do with the
> great variety of local delivery agents, and MUAs.  Maildir ensures
> that even if an OS has a problem with flock(), or if you have a
> delivery agent that's been incorrectly compiled (i.e. if procmail is
> compiled using flock and a pop3d using dot-locking) you can't lose a
> thing, and won't ever have to worry.  This kind of error can happen
> any time you re-compile any of your mail tools.

I compile my mail tools once, and I make sure I use the correct locking
procedures.  Locking problems with email tools are more a case of user 
error than anything else.  Erm, s/user/sysop/
The only people who have to recompile mail tools constantly are those
running Qmail as they need to get standard servers like pop3 and imap
to read Maildir-format boxes.  If they choose the wrong locking technique,
that's their problem and fault.  This was my point, btw, having to recompile
all the standard mail tools to support Maildir folders introduces new 
problems that one must be aware of or they'll bite you eventually.  Other
MTA's do not have such problems since they are compatible.

> > If you're using qmail for the speed, try Zmailer instead.  It's
> > easier to get going, the documentation is accurate, the people
> > are friendly, you don't need to mess around a _lot_ (at all, even)
> > to get client applications working, plus its faster anyway.
> 
> Wow, zmailer's easier to get going?  Is that why it couldn't pre48
> auto-configure itself for redhat 5?  The documentation is a bit on the
[snip]

If you insist on using bleeding-edge Zmailer trees, especially on production
systems, you deserve everything you get.  Same goes for any software, not
just Zmailer.

> Please get your facts straight, and don't spread FUD just because you
> don't like the product.  Qmail is designed and written
> clearly, simply, and securely.  It happens to beat the pants off of
> anyting else in terms of actual speed.  

How about you get your own facts straight Mr Know-it-all.  I did use
Qmail from about 0.8x and advocated it to a few people/places.  I
liked it until the day I had to do more than simply relay and deliver for
a single host, whereupon it self-destructed.
Who cares if it can push out 400,000 emails a day, when 399,000 of them
are going to bounce because it can't do virtual hosting?  Or the same
amount are spam messages because its anti-spam routines do not work?
What people want is a RELIABLE mail service.  I couldn't give a rats arse
if Qmail could push out 6 billion messages a minute whereas sendmail can
only do 100 messages if my mail server only recieves 20 messages a minute
and requires the features sendmail has that qmail doesn't.

> A quick note: Zmailer used to, and still may use an algorithm that
> allocates vmem exponentially, so using it to deliver large lists can
> become impractical quickly.  The router queue can easily be overloaded
> by any significant volume of email.  The the point that I had to
> abandon zmailer was where the order of 10-20 thousand messages would
> take over 12 hours to deliver, where with qmail the same queue will
> clear in under 2 hours.

Funny, vger.rutgers.edu appears to have no such problem with Zmailer
pushing out the various mailing lists hosted on it.  I doubt you're
going to find a mail server pushed harder than that one...

> Also please remember: if a product that's being used actively is not
> updated for a long time, and its users aren't complaining, it is a
> *good* thing.  It means that no significant problems have been found,

Is that truly a good thing?  Just because they haven't been found doesn't
mean that they're not there.  In the case of Qmail, it has recieved 
nowhere near the amount of testing as BSD sendmail, hence the reason why
more bugs and security holes have been found in sendmail.  Qmail advocates
will falsely claim this means Qmail is more secure.
Funnily enough, the DoS attack with the transport agent in Qmail was
never officially fixed in 1.01 and no patches for it were made available
from the Qmail site(s).  Sure, it's quite simple to use resource limits
to work around the effects of the bug in Qmail, but this doesn't cure
the bug - only covers up its droppings.

> and in the case of qmail it meant that the author was putting his next
> version under significant regression tests so no new version would be
> released until it was proveably stable and compatible.  

>From my point of view considering the large number of patches and features
available on the web site, it meant that the author was too busy or lazy
or whatever to continue development until well over a year later with the
release of 1.02.

-- 
Matthew Hawkins <matt@goldweb.com.au> |
WWW: http://www.goldweb.com.au/~matt/ | "Do not taunt happy fun troll."
UID 0 @ Goldweb Internet +61262530059 |
PGP: 1024/273E35E1  -  01 8D 6C 62 4C D1 05 3D  0F 59 5B E3 81 9F 59 B9