Uh-oh. Here comes the DJB-quotation squad. Quoting likot ([EMAIL PROTECTED]):
> no patches - install fastforward or/and dotforward Huh? What am I missing, here? To the best of my recollection, _those_ don't add support for sendmail's command-line switches: Fastforward adds /etc/alias support. Dotforward adds .forward support. > false - qmail supports /var/spool/mail, $HOME/Mailbox and Maildir > style deliveries Hmm. I didn't remember qmail being able to drop off mail in mbox format, but on reflection it's indeed a matter of the mail delivery agent. Thus, all that's required is getting your MTA talking fruitfully to your preferred MDA (e.g., procmail, maildrop, etc.). For qmail, this amounts to configuring /var/qmail/rc correctly. There's an example /var/qmail/rc for procmail provided. Point of information for you: Saying "mbox format" _doesn't_ imply /var/spool/mail. The MDA might be configured to use ~/Mail/mbox, or any of a variety of alternatives. The assumption to the contrary is a Bernsteinism. I suggest wider reading. > (IMHO maildir is the way to go ) Gratuitous advocacy noted without further comment. I figure admins will make their own decisions based on their own needs. > i agree, but most people don't need most of the patches ( i.e. diff. > people diff. need ) Gratuitous advocacy noted without further comment. I figure admins will make their own decisions based on their own needs. > well the basic flow in SENDMAIL is the design, any changes will be > futile if they can't get the design correctly ( i.e. postfix and > qmail) In rhetoric, we call this fallacy "begging the question". This means basing your conclusion on a doubtful premise that is carefully unexamined. E.g., you haven't shown that a monolithic binary MTA cannot be "correct design" according to any reasonable understanding of the term. Why? Because you cannot. Nor can anyone else. Please note: "Correct design" is _not_ defined as "Our Hero said this is the only acceptable way." > it's about style, qmail is ported to MOST/almost ALL UNIX platform Painfully and very manually, I wouldn't doubt: I must say that writing one's own substitute for stdio.h is a bit pathological. > ...and qmail is the most easiest to install from source ( as to my > opinion,your's may differ) As long as you don't try to depart even minutely from the Approved Bernstein Way, yes. Want FHS compliance, for example? Good luck. (Yes, I _know_ Our Hero disapproves of the FHS. Gratuitous advocacy anticipated without further comment. I figure admins will make their own decisions based on their own needs.) >> Qmail's mail spool cannot be backed up or migrated to a different >> host, because it uses inode numbers. (Dan feels this is justified >> for performance reasons.) > > Not true anymore. Huh? Please explain. You referred me to qmail-queue. Here's the manpage: http://www.mathematik.uni-ulm.de/help/qmail/qmail-queue.8.html Reading through that, I don't see it. Are you talking about a different program? If you're talking about some wacko program that can _export_ qmail's inode-encoded spool contents so that a backup or copying program can get at them, then that's half a loaf, anyway. Almost as useful as being able to treat the spool as regular files. (But my interest in the minutiae of qmail administration is pretty small. I finally escaped having to administer the damned thing professionally in late 1999. Hated it. But chacun a son gout.) > hrmm postfix too right > http://www.postfix.org/faq.html#copying Hey, good point! I hadn't realised that Postfix also uses inode numbers in queue filenames. Will note that for the future. (I haven't run Postfix, only Sendmail, Qmail, and Exim.) >> Last, of course, qmail is the only one of the four under a >> proprietary licence -- > > let us just clear this thing up, most people think that you _can't_ > modify qmail's source which is wrong. [...] But I _don't_ think that. Nor did I say so. And what I said before _is_ precisely (and concisely) the issue. What you're bringing up is a tiresome, time-wasting red herring. > but please give him credit qmail is DJB's work all he ask is that you > don't distribute modified qmail and call it qmail.... He forbids distributing modified qmail under _any_ name without special permission. If you believe otherwise, show me. Quoting: "If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval." ( i think as for my opinion.... Gratuitous advocacy noted without further comment. >> the main consequence of which is that the project cannot be forked, >> and that if/when Dan loses interest or dies, without some additional >> licence grant the package will become effectively unmaintainable and >> a dead project. > > things can continue via patches. You'll note that I very specifically said -=effectively unmaintainable=-. An MTA that can be developed only via patches against a legacy codebase would be impractical and absurd. Obviously. And, absent some new permissions grant by Dan Bernstein or a successor copyright holder (e.g., an heir), it's _exactly_ the dilemma that the entire qmail and djbdns user communities will find themselves in, some day. Avoiding such situations, and favouring the right to fork as a general remedy, is the main (pragmatic) advantage of open source. -- Cheers, "I don't like country music, but I don't mean to denigrate Rick Moen those who do. And, for the people who like country music, [EMAIL PROTECTED] denigrate means 'put down'." -- Bob Newhart _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
