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

upgrading a production server to Qmail




more people out there are convinced that it's great than ones that are
not... people on the Qmail list won't tell me the bad things, so I'll ask
people around here. How easy is the upgrade? considdering:

some of my users have .forward files
I have a long alias list
I have many majordomo lists
I use a mailfilter I pipe to from .forward
I use IMAP right now... are Maildirs THAT much better that I should give
      IMAPd up? (no IMAP implementation for Qmail yet)

will I have to do a lot of "foot work", or is it semi-automatically
assimilating my system? I'd like to know about systems both big and small
(Yaron?), and with weird setups (UUCP? dial-up SMTP or fetchmail polling?)


for those who don't know Qmail too well yet, it's about time...
http://www.qmail.org

---------- Forwarded message ----------
Date: Mon, 03 Mar 1997 07:03:00 -0600
From: "Brian T. Wightman" <wightman@epsilon.acs.uwosh.edu>
To: Olaf Titz <olaf@bigred.inka.de>
Cc: djb-qmail@koobera.math.uic.edu
Subject: Re: Features (Re: Rejecting large messages) 

In message <19970301104041.11971.qmail@bigred.inka.de>,
  Olaf Titz wrote:
> > It'd only be more "resource friendly" for people that actually want to
> > use it.  For those that don't, it's unnecessary code bloat.
> 
> Okay, let's look at this argument closer for a moment. It is true for
> _every_ imaginable feature a program could have. For people who don't
> use it, it's "code bloat". For people who need it, it is a question of
> efficiency.
> 
> Just an example: because qmail can't rewrite headers, my current setup
> forces me to pass each and every message through qmail twice. I call
> this inefficient. (No, that it is still faster than smail does not
> matter for this argument.) Other people might call header rewriting
> code "bloat" just because they don't need them. The latter is the
> canonical approach towards every feature request on this list: "who
> does need that?", "you can do this with a handful of add-ons", etc.
> 
> There are a number of features that are often wanted because there is
> a need for them. Implementing them would _not_ constitute code bloat,
> given sufficient need. Or else we wouldn't need MTAs at all. The
> workarounds at the individual sites can be seen as just as bad.
> 
> Take this as a plea for less hostility towards feature requests.
> (I'm still missing a possibility for declaring a message remote, in
> contrast to virtualdomains which declares a message local...)
> 
> olaf

A couple of comments (I hope I am more awake this time than I have
been for my other posts).

It took me a while to wrap my mind around qmail's approach of doing
things, but once I started treating the qmail core like a part of a
toolbox (just like awk, sed, perl, ps, and other 'tools'), the light
went on.

Qmail is a very specific, small, and effecient tool for delivering
mail.  It is not a tool for header rewriting, bang path conversion,
mailing list management, or the like (I am talking about the core
here, not things like qlist).

If you start adding other things into the core (like header
rewriting), then you increase the risk of adding bugs into the core.
If you have a core that is bug-free (or the bug rate is negligibly
small), then you can _reliably_ use that tool as a key internal part
to larger systems, without having to worry about it doing something
unexpected.

If you use the tool as part of the system for rewriting addresses (ie:
write a program wrapper that handles address rewriting for a class of
mail - say outgoing), then you don't have to worry about the address
rewriting part affecting the rest of the systems that use the qmail
'tool' - the changes in the address rewriting part of the system are
isolated to that singe part of the system instead of the core.

Personally, I find myself writing much more robust code when I use
many small tools, each with a distinct function, and glue them
together with perl or some other scripting language.  I find the small
bit of overhead this causes to be more than acceptable when weighing
it against the bugs that adding a feature on to a tool (such as the
qmail core) generates.

Perhaps an archive of add-ons (wrappers) that can be "plugged-in" to
qmail to solve standard problems would help.

Nice job Dan.

Brian