If you are going to convert from Sendmail to QMail, count on the following-
1. You will have to be able to in your head understand the "metaphor" if
you will that Sendmail uses and the one that Qmail uses. They both think
about e-mail quite differently.
2. You will need to be able to pinpoint areas where potential conversion
mistakes are highly likely to occur, and double check these areas -
especially in chkrcpts, locals;
3. You will have to be able to react quickly. Plan on a highly tested
system requiring your full, nearly 24-hour-a-day, attention for a few days
after installation. Not so much because it needs it but because you *will*
find things which you hacked into sendmail and the pop server break on you.
Again, be especially cognizant of chkrcpts.
As a general rule -I would never recommend qmail to the system admin who
isn't completely confident in their abilities and who isn't good at
reacting quickly. Sendmail - once it actually *compiles* is actually
somewhat easier to configure because it is monolithic in nature. Qmail is
multiple programs working together (or against one another in some cases!).
One thing I had to learn was before where I could do killall
sendmail;sendmail -bd to reset the server, now I had to be careful because
it is quite possible to mistakenly use this approach in qmail with bad
results. Kill one daemon, and you learn quickly why they're called
"daemons" as the others turn against you (and call them legion).
Figure out supervise and tcpserver. I could tell from reading this list
that it would be better to jump fully into the project using these and
Maildirs with some slight impact on users than to try to build in this
functionality later on. Supervise is excellent because it makes controlling
the service very easy.
It took me five days to get back to where I was with sendmail in my first
Qmail install. I expected some trouble, though not quite that much, and
I've already posted to the list things that I felt were unnecessary
nuisances like the (i still say arrogant) linefeed problem. But the
interesting fact is within a matter of a day or two I was (and am) still
looking at dozens more way to expand the functionality this programset has
to offer. POP bulletins are a major asset, for example. These are things
that sendmail doesn't have, and that I will be able to do with QMail easily
with a little work.
Everything that is worth it, takes effort, dedication, learning,
adaptibility, and skill.
That's life.
-doug
>
>
>Should you install qmail ?
>---------------
>
>First of all, consider these:
>
>* You have to deinstall sendmail before starting to install qmail. While
>installing
> qmail, you won't be able to do mail. Also, you will probably make quite some
>changes to your fs, which makes it hard to just give up and reinstall
>sendmail.
> It's a good idea to completely backup your system so you'll be able to
>swap it
>back in once you really fall asleep and things are still not working.
>
>* There are some differences in securitymechanisms, for better or for worse.
>
>* Qmail is probably also more inviting to hackers, just because it's more
>human.
>
>* Some experience is necessary. It may take you some hours. Don't use an
>RPM (as of
>this date); qmail is _not_ fsstnd. Install it 'by hand', step by step.
>
>----------------
>
>Now,
>
>If you're just a single user, you have some sparetime left, you hate sendmail
>and like the fancy rumours about qmail, try it. Especially, if you've just
>installed
>your system out of the box, and never heard of sendmail, never had any mail,
>this is the moment to install qmail. Don't use sendmail, it's awfull.
>
>If you have a server with several users, things may get messy. You've never
>realised how many users you have untill they all start complaining,
>believe me,
>I know :-)
>
>If you're have problems with sendmail, qmail may be the solution. The other
>solution
>is to hire a Sendmail Guru, someone that actually read the book :-)
>
>But here are some of the things you're going to face:
>
>- qmail doesn't do /var/spool/mail. it tries to keep
>the mailboxes in the users' homedirectories (which is better). If you want
>to do that,
>move all your mbox files to the users' homedirs .. there u go. If you don't
>want that,
>read a whole lot of docs before you install qmail.
>
>-in fact, qmail-pop3d doesn't do any mbox format, it wants
>to use the Maildir format (which really is better). If you want to use
>that, you should
>convert all your mbox files to maildirs ... someway. In the package, there
>is a tool
>supplied to do the reverse: MailDir to Mbox files :-)
>
>- qmail-pop3d doesn't work without a passwordchecker. you need to get it
>somewhere
>online and change some lines in some initfiles to get it working.
>
>If all of the above 2 things scare you, don't use qmail-pop3d...you need to
>use some
>other popdeamon and get it to cooporate with qmail. There's a techy bit ....
>And then you're not really 'running qmail', you're just using some bits of
>the qmail package. Things may get tricky when all the bugs arrive and you
>need to update.
>
>-qmail doesn't do .forward files, it uses .qmail files (which are better).
>If you want
>to use them, edit and rename all .forward files ... ... there u go.
>There's also a patch (dotforward) for using .forward files.
>
>-qmail doesn't read /etc/aliases. It reads info from /var/qmail/ (which is
>better).
>...you get the point. Yes, there is a patch (fastforward) to run if you
>want /etc/aliases.
>
>--------------
>
>In practice, a lot of things didn't work at my server. I had to move all
>the mboxes,
>rename & edit all .forward files (dotforward barfed), and decided not to
>even try fastforward
>
>Things were still not working and I had to invent complex workarounds.
>A lot of handwork ... a week later, I had to do it all over again, to try
>and fix it.
>The users got funny errors and received all the mail they left on
>the server several times .... even on such a small system as mine,
> it was HELL.
>
>I'm glad I have it running & I like it.
>But would I have known all this, I wouldn't have done it.
>Sendmail, after all, was working fine.
>
>cu
>*PIKE*
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...*..P.i.k.e...*....
> mailto:[EMAIL PROTECTED]
>http://www.kw.nl/~pike - desktop
> icq: 4322610
>
>
> The Cathedral and the Bazaar
> by Eric S. Raymond
> http://www.redhat.com/knowledgebase/cathedral-bazaar.html
>
> I anatomize a successful free-software project, fetchmail, that was
> run as a deliberate test of some surprising theories about software
> engineering suggested by the history of Linux. I discuss these
> theories in terms of two fundamentally different development styles,
> the ``cathedral'' model of most of the commercial world versus the
> ``bazaar'' model of the Linux world. I show that these models derive
> from opposing assumptions about the nature of the
> software-debugging task. I then make a sustained argument from the
> Linux experience for the proposition that ``Given enough eyeballs, all
> bugs are shallow'', suggest productive analogies with other
> self-correcting systems of selfish agents, and conclude with some
> exploration of the implications of this insight for the future of software.
