Rick Moen wrote: >Uh-oh. Here comes the DJB-quotation squad. > >Quoting likot ([EMAIL PROTECTED]): > > hehe :)
> > >>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. > > qmail has a sendmail compat binary <PREFIX>/qmail/bin/sendmail some switches are not supported tho :) > > >>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. > > _ 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]
