well, a few comments:
1) sendmail does not come with a pop daemon, so throw anything about pop
out.
2) the only reason you may find it hard to deal with qmails new rules for
mailboxes and alias files is the fact that most major unix releases come
with sendmail preinstalled, so it seems that it has become the defacto
standard of how unixen should be setup, of course your opinion would be
different had qmail be the standard.
-xs
end
+-------------------------------------+
|Greg Albrecht KF4MKT [EMAIL PROTECTED]|
|Safari Internet www.safari.net|
|Fort Lauderdale, FL 1-888-537-9550|
+-------------------------------------+
On Wed, 28 Apr 1999, Pike wrote:
>Hi
>
>I wish I had read a mail like this before I started installing qmail on my
>server,
>which is exactly why I'm writing it. Call it frustration.
>
>There may be a lot of unjust information in here! If you're seriously
>reading this,
>read all the replies too. I hope someone who _really_ knows qmail will correct
>me where I'm wrong.
>
>Qmail claims it's a replacement for sendmail.
>They say 'after installing, read the docs,there are some minor differences'
>:-) LOL! But beware. That's vaporware.
>
>Once you have it up & working, qmail is great. It's better than sendmail.
>It's easier to understand, monitor, configure. Read all about it somewhere
>else.
>
>Qmail is a package of programs, all neatly documented and worked out, to do
>something like sendmail does. It does it a whole lot different though. If
>you want
>it to behave like sendmail, you need to do a lot of things _after_
>installing qmail.
>You even need to install things that are not in the package, which you have
>to find
>online somewhere (checkpasswd ?). Therefore, qmail is not a (complete)
>replacement
>for sendmail.
>
>
>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.
>
>
>
