Re: How about maildir support?

[Soren Harward <soren cinternet net>]

Can we end this Qmail / sendmail Holy War?  I subscribed to this list to
hear about GNOME -- not mail daemons.

-----------------------------------------------------------------------
 Soren Harward                               | Windows 95 DOES come
 Internet Information Systems Administrator  | with a tool to rebuild
 Cinternet, Inc.                             | a corrupt Registry.
 Voice: 891-1228         soren@cinternet.net | It's called FDISK.
 http://www.cinternet.net/~soren/            | 
-----------------------------------------------------------------------

On Thu, 18 Jun 1998, Matthew Hawkins wrote:

>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
>
>
>-- 
>         To unsubscribe: mail gnome-list-request@gnome.org with 
>                       "unsubscribe" as the Subject.
>