Re: A firestorm of protest?
Chris Garrigues wrote: "Upgrade" suggests adding features, rather more than "patch" does; patches are often released to fix bugs. How about "addition" or "extension"? we need something that vaguely impugns the patch, without implying that the patch is required, and we wish to keep current meaning of "patch" and be consistent with all current habits. My nomination is, drumroll please "non-standard option" or , even more impugnly, "unsupported option" These could even be ranked in order of sanity, from the ones that get mentioned all the time on the list, to the ones that are heretical to "official" reccommendations. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "Live fast, die young, and leave a beautiful corpse"
Re: A firestorm of protest?
On Wed, 17 Jan 2001, Dave Sill wrote: DJB has very clearly expressed disdain for My question - should we not to wait for a DJB own opinion. This same, it seems my, were well to avoid a discusion behind his back. Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: A firestorm of protest?
Piotr Kasztelowicz [EMAIL PROTECTED] wrote: On Wed, 17 Jan 2001, Dave Sill wrote: DJB has very clearly expressed disdain for My question - should we not to wait for a DJB own opinion. Er, what do you think "DJB has very clearly expressed disdain" means? See: http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/08/msg00543.html And the rest of the thread. This same, it seems my, were well to avoid a discusion behind his back. Er, he's subscribed to this list. In what way is this discussion behind his back? -Dave
Re: A firestorm of protest?
Hello Er, he's subscribed to this list. In what way is this discussion behind his back? Ok, It's true (but very rare writes to the list :-) Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: A firestorm of protest?
Henning Brauer [EMAIL PROTECTED] writes: I see exactly two patches which could be part of stock qmail: the AOL dns patch More likely, qmail will be updated to use the djbdns client library. AIUI, this would solve the 512-byte-response problem. paul
Re: A firestorm of protest?
On Thu, Jan 18, 2001 at 02:08:09PM -0500, Paul Jarc wrote: Henning Brauer [EMAIL PROTECTED] writes: I see exactly two patches which could be part of stock qmail: the AOL dns patch More likely, qmail will be updated to use the djbdns client library. AIUI, this would solve the 512-byte-response problem. And if zeroseek comes along, that no doubt will obviate the big-todo patch. What's left? Oh, larger concurrency. DJB has already referred to that need in TODO. For my money, creating interfaces that allow some of the patches to exist as standalone programs is probably a useful strategy. Regards.
RE: A firestorm of protest?
Peter Cavender writes: Laurence Brockman writes: I'm going to jump into the discussion here and ask why we don't do something like perl has done with cpan? They don't call them patches, or upgrades, or anything else. They call them Modules and have a central repository that users can go and search from. I think this would be ideal for qmail.org site... He's done *just that*. That's what program delivery in a .qmail file is for. That's what qmail-getpw is for. That's what users/assign is for. That's what qmail-queue is for. Nobody patches the source of perl -- they just go to the published APIs and add things. So why are we patching qmail instead of writing replacements? What do you mean by "writing replacements"? That people should write their own mail servers, rather than try to enhance qmail? No. I think that people who want qmail-smtpd to have a badrcptto file as well as a badmailfrom (for example) should make a Makefile, change qmail-smtpd.c, include the necessary files, and package it up. There's no reason why they couldn't include the patch file as well. My point being that most things which are called patches could just as easily be stand-alone pieces of software. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
RE: A firestorm of protest?
On Wed, 17 Jan 2001, Russell Nelson wrote: Nobody patches the source of perl -- they just go to the published APIs and add things. So why are we patching qmail instead of writing replacements? Nice comparison...of pines and apples. Adding badrcptto (btw: this is a very useful thing) or big-todo patches to qmail is like changing the semantics of hashes in Perl. Unlike Perl, qmail has no built-in hooks for such drastic changes (well, badrcptto can be "implemented" with a front-end SMTP daemon but this is as absurd as using recordio to make qmail-smtpd log some diagnostic messages...this is not modularity but onion-style bloat). --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation."
RE: A firestorm of protest?
[EMAIL PROTECTED] wrote: As for updating qmail, I would be all for a new version of qmail with some of the more useful (nearly mandatory) plugins already added. A couple I can think of is the oversize DNS packet patch for qmail, Nowhere near mandatory. and possibly qmail-scanner ( with the option to disable it if not needed). After last nights virus fiasco on this list, is there anyone who doesn't think it might be a welcome addition to a standard qmail install? : ) Yep: me. Which is worse, 20 messages sent to a list with the same virus, or 20 messages sent to a list with the same virus followed by 20*N warning messages from N friendly virus scanners around the world? As for who would decide what is useful and what isn't? I would assume DJB or perhaps a small panel of qmail experts appointed by DJB could vote on additions to the mail install. DJB has already decided which he considers useful enough to warrant a new release: none of them. -Dave
Re: A firestorm of protest?
On Tue, Jan 16, 2001 at 07:48:05PM -0500, Aaron Carr wrote: As for updating qmail, I would be all for a new version of qmail with some of the more useful (nearly mandatory) plugins already added. A couple I can think of is the oversize DNS packet patch for qmail, and possibly qmail-scanner ( with the option to disable it if not needed). After last nights virus fiasco on this list, is there anyone who doesn't think it might be a welcome addition to a standard qmail install? : ) yes. Don't bloat qmail. One of the greatest things about qmail is its size. You may want to discuss the uselessness of virii scanners with Felix ;-)) As for who would decide what is useful and what isn't? I would assume DJB or perhaps a small panel of qmail experts appointed by DJB could vote on additions to the mail install. I see exactly two patches which could be part of stock qmail: the AOL dns patch and Russels qmtp/mxps-patch for qmail-remote. -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany
Re: A firestorm of protest?
Henning Brauer [EMAIL PROTECTED] wrote: I see exactly two patches which could be part of stock qmail: the AOL dns patch and Russels qmtp/mxps-patch for qmail-remote. Forget about the DNS mods, DJB has very clearly expressed disdain for them. I'd vote for the MXPS and bigconcurrency mods. -Dave
Re: A firestorm of protest?
On Wed, Jan 17, 2001 at 09:02:38AM -0500, Dave Sill wrote: and possibly qmail-scanner ( with the option to disable it if not needed). After last nights virus fiasco on this list, is there anyone who doesn't think it might be a welcome addition to a standard qmail install? : ) Yep: me. Which is worse, 20 messages sent to a list with the same virus, or 20 messages sent to a list with the same virus followed by 20*N warning messages from N friendly virus scanners around the world? I'd just like to point out that you can't blame Qmail-Scanner for that. Qmail-Scanner *NEVER* sends "your message was infected" messages to mailing-lists. It explicitly looks for signs that the message is from a list (-owner|-return|Precedence: junk, etc) and if found only Email's the Qmail-Scanner administrator. Others (esp. commercial) bore us silly with their alerts... -- Cheers Jason Haar Unix/Special Projects, Trimble NZ Phone: +64 3 9635 377 Fax: +64 3 9635 417
Re: A firestorm of protest?
At 23:46 15.1.2001 +0100, Henning Brauer wrote: On Mon, Jan 15, 2001 at 03:18:10PM -0500, Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. I'd just rename it from patches to "additional functionality" or something like that. I guess, thats the correct approach. It would be very helpful for the qmail community to "organize" the patches - or have them organized. From my point of view - actually how I organize the mails coming from this mailing list - one should differentiate between "Add-Ones" (eg. scripts working within .qmail and the brand new Log-Analyzer in perl) leaving the product unchanged and "Miscellaneous enhancements" covering the patches against the code. Both should be organized by feature and/or qmail module. This would help to keep track of the patches. When I initially created the SPAMCONTROL patch, I had the same problem like everybody has: Here and there is a useful piece of code (=patch) which I integrated into a larger set. But this is not as trivial as it seems. While qmail 1.03 is since years in the field SMTP development is going further (eg. STARTTLS and SASL) and of cause, everybody is interesting employing those features. It is necessary to integrate those enhancements (even though they are not coming from DJB and might be as complex as qmail-ldap) in order to be competitve. In addition, since qmail is prefered by ISPs, there requirements are different wrt the end user. Therefore, we have today packages like vpopmail, sqwebmail and others which enhence qmail and it's complexity significantly. Maybe it would worthwile to consider this as well as an "organizational" item for qmail.org. cheers. eh. +---+ | fffhh http://www.fehcom.deDr. Erwin Hoffmann | | ff hh| | ffeee ccc ooomm mm mm Wiener Weg 8 | | fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln| | ff ee eee hh hh cc oo oo mm mm mm| | ff eee hh hh cc oo oo mm mm mm Tel 0221 484 4923 | | ff hh hhccc ooomm mm mm Fax 0221 484 4924 | +---+
Re: A firestorm of protest?
Thus spake Piotr Kasztelowicz ([EMAIL PROTECTED]): If you want to use bloated, unreliable, immensely fat software with a Where I have written, that EACH patch? Only USEFUL patch. The world goes forward! There is no objective measure for the usefulness of a patch. Thus, there will be endless fruitless discussions that make everyone feel bad, and in the end either Dan does not include the patch, which means that it was all for naught, or Dan does include the patch, and then the discussion will also have been for naught since Dan already includes patches he likes without external discussions (the pop3 daemon is based on someone else's code). Felix
Re: A firestorm of protest?
Thus spake Kris Kelley ([EMAIL PROTECTED]): If you want to use bloated, unreliable, immensely fat software with a nice author who will include every patch anyone sends him, switch to Exim. I mean it! Please go away and use Exim. It has all the features anyone could ever want from an MTA, and around 20 million more features. Does Exim also come with a nice mailing list that doesn't demand the exile of people with dissenting opinions? Exim is luser friendly. That's why it is luser software. Felix
Re: A firestorm of protest?
On Tue, 16 Jan 2001, Felix von Leitner wrote: There is no objective measure for the usefulness of a patch. Thus, there will be endless fruitless discussions that make everyone feel bad ... Lets so Dan take way of further progress of qmail himself ...:-) Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
RE: A firestorm of protest?
I'm going to jump into the discussion here and ask why we don't do something like perl has done with cpan? They don't call them patches, or upgrades, or anything else. They call them Modules and have a central repository that users can go and search from. I think this would be ideal for qmail.org site... Just my $0.02 Laurence -- Laurence Brockman Unix Administrator Videon Cablesystems Alberta Inc 10450-178 St. Edmonton, AB T5S 1S2 [EMAIL PROTECTED] (780) 486-6527 -Original Message- From: Erwin Hoffmann [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 1:39 AM To: Henning Brauer; qmail-list Subject: Re: A firestorm of protest? At 23:46 15.1.2001 +0100, Henning Brauer wrote: On Mon, Jan 15, 2001 at 03:18:10PM -0500, Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. I'd just rename it from patches to "additional functionality" or something like that. I guess, thats the correct approach. It would be very helpful for the qmail community to "organize" the patches - or have them organized. From my point of view - actually how I organize the mails coming from this mailing list - one should differentiate between "Add-Ones" (eg. scripts working within .qmail and the brand new Log-Analyzer in perl) leaving the product unchanged and "Miscellaneous enhancements" covering the patches against the code. Both should be organized by feature and/or qmail module. This would help to keep track of the patches. When I initially created the SPAMCONTROL patch, I had the same problem like everybody has: Here and there is a useful piece of code (=patch) which I integrated into a larger set. But this is not as trivial as it seems. While qmail 1.03 is since years in the field SMTP development is going further (eg. STARTTLS and SASL) and of cause, everybody is interesting employing those features. It is necessary to integrate those enhancements (even though they are not coming from DJB and might be as complex as qmail-ldap) in order to be competitve. In addition, since qmail is prefered by ISPs, there requirements are different wrt the end user. Therefore, we have today packages like vpopmail, sqwebmail and others which enhence qmail and it's complexity significantly. Maybe it would worthwile to consider this as well as an "organizational" item for qmail.org. cheers. eh. +---+ | fffhh http://www.fehcom.deDr. Erwin Hoffmann | | ff hh| | ffeee ccc ooomm mm mm Wiener Weg 8 | | fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln| | ff ee eee hh hh cc oo oo mm mm mm| | ff eee hh hh cc oo oo mm mm mm Tel 0221 484 4923 | | ff hh hhccc ooomm mm mm Fax 0221 484 4924 | +---+
Re: A firestorm of protest?
At 07:21 PM 1/15/2001, you wrote: On Mon, 15 Jan 2001, Felix von Leitner wrote: If you want to use bloated, unreliable, immensely fat software with a Where I have written, that EACH patch? Only USEFUL patch. The world goes forward! Ah...but what is useful to thee may not be useful to me :o) Or many others for that matter. Who decides what's useful? Jer
Re: A firestorm of protest?
On Mon, 15 Jan 2001 15:18:10 -0500 (EST), Russell Nelson [EMAIL PROTECTED] wrote: Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that This might be too simple, but why not call them 'modifications' or 'customi[sz]ations'? That doesn't seem to have the implied wrongness... end -- Jurjen Oskam * carnivore! * http://www.stupendous.org/ for PGP key assassinate nuclear iraq clinton kill bomb USA eta ira cia fbi nsa kill president wall street ruin economy disrupt phonenetwork atomic bomb sarin nerve gas bin laden military -*- DVD Decryption at www.stupendous.org -*-
Re: A firestorm of protest?
"Chris Garrigues" [EMAIL PROTECTED] wrote: From: "David Dyer-Bennet" [EMAIL PROTECTED] "Upgrade" suggests adding features, rather more than "patch" does; patches are often released to fix bugs. How about "addition" or "extension"? I vote for "source code plug-ins". :-) -Dave
Re: A firestorm of protest?
: I vote for "source code plug-ins". :-) : : -Dave : Service pack 0.1 Beta? TonyCam
Re: A firestorm of protest?
* Dave Sill [EMAIL PROTECTED] writes: "Chris Garrigues" [EMAIL PROTECTED] wrote: From: "David Dyer-Bennet" [EMAIL PROTECTED] "Upgrade" suggests adding features, rather more than "patch" does; patches are often released to fix bugs. How about "addition" or "extension"? I vote for "source code plug-ins". :-) Ummm... Nope. A plug-in is something one plugs in. Like relay-ctrl. Patches are not. A tool to magically merge patches one needs into one big patch (like Felix' jumbo patch) would be really neat (like, smtp-auth fails with the other patches I need applied).
Re: A firestorm of protest?
* Laurence Brockman [EMAIL PROTECTED] writes: I'm going to jump into the discussion here and ask why we don't do something like perl has done with cpan? They don't call them patches, or upgrades, or anything else. They call them Modules and have a central repository that users can go and search from. I think this would be ideal for qmail.org site... A module is not a patch. You can apply as many well written modules as you like - but you cannot simply patch away at an existing code base. -- Robin S. Socha http://socha.net/
RE: A firestorm of protest?
how about: stuff-to-make-qmail-a-reasonable-tool-to-use-with-a-few-million-users-that-m ay-encourage-others-to-write-stuff-that-may-introduce-security-holes-and-mak e-the-original-author-uneasy i'm grateful that qmail is security bug free. but i have the need to control the max number of recipients per email and to prevent broken ms SMTP servers from bringing my servers to their knees, etc. while i wrote a similar "enhancement" to qmail to control max rcpt's to what was on the qmail.org site (before i knew to cruise the site for good stuff), i wouldn't want to do that for things like big todo "patch" and perhaps the big concurrancy "patch". if i had a few or ten thousand users, i'd gladly use qmail "out of the box." i'd have someone watch the logs 24/7 and if they see too many connections from one IP, block them with a tcpserver rule. unfortunately i have too many servers and too many users to be doing that. i need the help that others have provided to assist qmail be accepted and usable in many heterogeneous real world environments. -- Michael Boyiazis [EMAIL PROTECTED] Mail Architect, NetZero, Inc.
Re: A firestorm of protest?
"Robin S. Socha" wrote: * Dave Sill [EMAIL PROTECTED] writes: "Chris Garrigues" [EMAIL PROTECTED] wrote: From: "David Dyer-Bennet" [EMAIL PROTECTED] "Upgrade" suggests adding features, rather more than "patch" does; patches are often released to fix bugs. How about "addition" or "extension"? I vote for "source code plug-ins". :-) Ummm... Nope. A plug-in is something one plugs in. Like relay-ctrl. Patches are not. A tool to magically merge patches one needs into one big patch (like Felix' jumbo patch) would be really neat (like, smtp-auth fails with the other patches I need applied). Why not put together something like that.. a versioning tool for qmail and patches... have a published standard format for dealing with it and specifing the details for each patch (Module).. Jonathan Smith
Re: A firestorm of protest?
"Robin S. Socha" [EMAIL PROTECTED] wrote: * Dave Sill [EMAIL PROTECTED] writes: I vote for "source code plug-ins". :-) Ummm... Nope. Nope what? Nope, I don't vote for "source code plug-ins"? Or nope, "source code plug-ins" is not a good rename for "patches"? You're right either way--as the smiley clearly indicates. Seriously, I suggest we call them "modifications", or "mods" for short. -Dave
Re: A firestorm of protest?
+ Dave Sill [EMAIL PROTECTED]: | Seriously, I suggest we call them "modifications", or "mods" for | short. This whole discussion reminds of a Lisp story I heard many years ago. These folks were making a software package based on Lisp. A manager actually requested that they rename the garbage collector because it (the name) implied that their program produced garbage! But of course, if we are to bend to this silliness in the first place, then Dave's suggestion sound good to me. - Harald
RE: A firestorm of protest?
I hate to add to the barrage of email about this, but, I feel that I must throw in my 2 cents for the record. My vote for the web site would be qmail-plugins or something to that effect. It does not imply any shortcoming, defect or bug, it simply states that some my find each particular plugin useful, while others may have no use for it at all. As for updating qmail, I would be all for a new version of qmail with some of the more useful (nearly mandatory) plugins already added. A couple I can think of is the oversize DNS packet patch for qmail, and possibly qmail-scanner ( with the option to disable it if not needed). After last nights virus fiasco on this list, is there anyone who doesn't think it might be a welcome addition to a standard qmail install? : ) As for who would decide what is useful and what isn't? I would assume DJB or perhaps a small panel of qmail experts appointed by DJB could vote on additions to the mail install. As I said, these are just my 2 cents from someone not far into the qmail journey. I'm picking it up when and where I can. Aaron Carr
Re: A firestorm of protest?
On 17-Jan-01 at 01:05, Aaron Carr ([EMAIL PROTECTED]) wrote: I hate to add to the barrage of email about this, but, I feel that I must throw in my 2 cents for the record. My vote for the web site would be qmail-plugins or something to that effect. It does not imply any shortcoming, defect or bug, it simply states that some my find each particular plugin useful, while others may have no use for it at all. Why not "Source Code Options" As for updating qmail, I would be all for a new version of qmail with some of the more useful (nearly mandatory) plugins already added. A couple I can think of is the oversize DNS packet patch for qmail, and possibly qmail-scanner ( with the option to disable it if not needed). After last nights virus fiasco on this list, is there anyone who doesn't think it might be a welcome addition to a standard qmail install? : ) But what if someone comes along with the 'killer DNS Option' and a much better scanner/detector of the next brew of spam/virus/worm? As for who would decide what is useful and what isn't? I would assume DJB or perhaps a small panel of qmail experts appointed by DJB could vote on additions to the mail install. Stan The Computer Man aka: Stanton Fields -- http://www.gate.net/~stan The Lab called... Your brain is ready!
Re: A firestorm of protest?
Thus said "Robin S. Socha" on 16 Jan 2001 20:47:55 +0100: A module is not a patch. You can apply as many well written modules as you like - but you cannot simply patch away at an existing code base. Unless you write code in Lisp... :-) Andy -- [---[system uptime]] 7:16pm up 75 days, 21:36, 5 users, load average: 1.38, 1.35, 1.38
RE: A firestorm of protest?
Laurence Brockman writes: I'm going to jump into the discussion here and ask why we don't do something like perl has done with cpan? They don't call them patches, or upgrades, or anything else. They call them Modules and have a central repository that users can go and search from. I think this would be ideal for qmail.org site... He's done *just that*. That's what program delivery in a .qmail file is for. That's what qmail-getpw is for. That's what users/assign is for. That's what qmail-queue is for. Nobody patches the source of perl -- they just go to the published APIs and add things. So why are we patching qmail instead of writing replacements? -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
RE: A firestorm of protest?
Laurence Brockman writes: I'm going to jump into the discussion here and ask why we don't do something like perl has done with cpan? They don't call them patches, or upgrades, or anything else. They call them Modules and have a central repository that users can go and search from. I think this would be ideal for qmail.org site... He's done *just that*. That's what program delivery in a .qmail file is for. That's what qmail-getpw is for. That's what users/assign is for. That's what qmail-queue is for. Nobody patches the source of perl -- they just go to the published APIs and add things. So why are we patching qmail instead of writing replacements? What do you mean by "writing replacements"? That people should write their own mail servers, rather than try to enhance qmail?
A firestorm of protest?
I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. I've found a couple of places where Dan decries patches: http://msgs.securepoint.com/cgi-bin/get/qmail9812/214/1/2/1/3/2/1/2/1.html http://msgs.SecurePoint.com/cgi-bin/get/qmail9905/164/3.html Somewhere he recommends that people make a copy of the necessary parts of his code and distribute the changed code as a separate package. Can anybody find it for me? I've failed to find it in nearly an hour of archive searching. I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: A firestorm of protest?
Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. I've found a couple of places where Dan decries patches: http://msgs.securepoint.com/cgi-bin/get/qmail9812/214/1/2/1/3/2/1/2/1.html http://msgs.SecurePoint.com/cgi-bin/get/qmail9905/164/3.html Somewhere he recommends that people make a copy of the necessary parts of his code and distribute the changed code as a separate package. Can anybody find it for me? I've failed to find it in nearly an hour of archive searching. I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. I would leave it as it is. Most people whom see patches assume in qmail's case that these are additions, as they are all described as such, and none imply any errors / problems. qmail has grown in popularity with these patches, and as long as they are described as they are then it will continue to grow. I use a few (5) of these and would continue to. Thats my 2 euro worth! Greg -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes on 15 January 2001 at 15:18:10 -0500 I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. A "patch" is also a recognized way to make an upgrade. I've found a couple of places where Dan decries patches: http://msgs.securepoint.com/cgi-bin/get/qmail9812/214/1/2/1/3/2/1/2/1.html http://msgs.SecurePoint.com/cgi-bin/get/qmail9905/164/3.html Somewhere he recommends that people make a copy of the necessary parts of his code and distribute the changed code as a separate package. Can anybody find it for me? I've failed to find it in nearly an hour of archive searching. I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. I think this is a very bad idea. My primary reason is that it's easier to apply a patch against updated main code than it is to integrate the changes from that updated main code into a standalone program. Also, some things are much better implemented as a change to the existing programs, rather than as an additional layer of programs. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
Greg Cope [EMAIL PROTECTED] wrote: Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. Most people whom see patches assume in qmail's case that these are additions, as they are all described as such, and none imply any errors / problems. Perhaps then the only change necessary is to change the semantics of the qmail.org site? Instead of "so-and-so has written a patch to...", change it to "addition" or "add-on" or whatever. Personally, I use Russell's big-todo and qmtpc patches, along with Bruce Guenter's /var/qmail/owners patches, and a few others, and I don't consider any of them to be bugs in Dan's pristine qmail -- they're simply conveniences, in much the same way that having power brakes in a Cadillac doesn't imply that manual brakes in a Chevette is a safety hazard. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: A firestorm of protest?
David Dyer-Bennet writes: I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. I think this is a very bad idea. My primary reason is that it's easier to apply a patch against updated main code than it is to integrate the changes from that updated main code into a standalone program. If Dan was putting out daily versions of qmail, sure. But we've had qmail-1.03 for several years now. Also, some things are much better implemented as a change to the existing programs, rather than as an additional layer of programs. Try applying two patches to the same program. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: A firestorm of protest?
Hello Perhaps then the only change necessary is to change the semantics of the qmail.org site? Instead of "so-and-so has written a patch to...", change it to "addition" or "add-on" or whatever. Qmail ver 1.03 does not already "young" software. How about to suppose Dan to make the new version - perhaps made with cooperation with all peoples, who have created useful patches and additional softwares, so that this all will be included to new version? Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: A firestorm of protest?
Russell Nelson wrote: Also, some things are much better implemented as a change to the existing programs, rather than as an additional layer of programs. Try applying two patches to the same program. That's not necessarily a problem, particularly when the patches affect different areas of the code. On the other hand, imagine there is a program that two people have written additions for, and you want to include both of those additions. If each person releases the complete source to their version of the program, instead of a patch to the original source, you'd have to wade through the program source, twice, to figure out where the modifications are and how to combine them. This problem can be circumvented by storing the complete source for every possible combination of additions, but that's going to quickly max out your storage space, not to mention the logistical nightmare of figuring out who needs to give permission and who gets credit, etc. ---Kris
Re: A firestorm of protest?
Thus spake David Dyer-Bennet ([EMAIL PROTECTED]): Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. A "patch" is also a recognized way to make an upgrade. The word "upgrade" also implies that there is something wrong or inferior with the original qmail. That said, while converting the patches into standalone packages would be better for political reasons, it would make it harder for me to maintain my qmail, because that is basically stock qmail with the AOL-DNS-fix, starttls and another small patch. Merging patches is far easier than merging divergent codebases. So, in effect, the changed policy would force me to download the qmail source code four times, run diff to get patches, and then merge those patches. I don't think political decisions should make life harder for all of us. I'd rather see www.qmail.org be changed so that you would have to click through a banner page that clearly states that none of those patches is necessary to make qmail any more secure, more reliable or faster. Please don't cripple my work with qmail in the vain attempt to make stupid people understand. They won't. That's why they are stupid in the first place. Russ, if you desire, please put a few explaining words over the patch section, and then proceed to ignore the idiots. It will make your life easier and the idiots will die out or move back to Exchange and it will save all of us a lot of stress. Felix
Re: A firestorm of protest?
Thus spake Piotr Kasztelowicz ([EMAIL PROTECTED]): Perhaps then the only change necessary is to change the semantics of the qmail.org site? Instead of "so-and-so has written a patch to...", change it to "addition" or "add-on" or whatever. Qmail ver 1.03 does not already "young" software. How about to suppose Dan to make the new version - perhaps made with cooperation with all peoples, who have created useful patches and additional softwares, so that this all will be included to new version? ARGH NO! GO AWAY, Piotr! The reason why qmail is reliable, fast, secury, easy to maintain and all around a nice piece of software is because Dan does _not_ include everyone's patches and pet features! If you want to use bloated, unreliable, immensely fat software with a nice author who will include every patch anyone sends him, switch to Exim. I mean it! Please go away and use Exim. It has all the features anyone could ever want from an MTA, and around 20 million more features. Felix
Re: A firestorm of protest?
On Mon, 15 Jan 2001, Piotr Kasztelowicz wrote: Dan to make the new version - perhaps made with cooperation with "Dan" and "cooperate" on the same line... all peoples, who have created useful patches and additional softwares, useful additions becoming standard? that'll be the day. See, these things that are really needed to get any use out of qmail, aren't supported... won't be supported, etc., as they make qmail less secure, less efficient and, well, just no longer qmail. I'm not trying to be too negative here. I have come the conclusion that I need to use qmail and be happy with qmail for what it is, and not try to change it. Scott
Re: A firestorm of protest?
Felix von Leitner wrote: If you want to use bloated, unreliable, immensely fat software with a nice author who will include every patch anyone sends him, switch to Exim. I mean it! Please go away and use Exim. It has all the features anyone could ever want from an MTA, and around 20 million more features. Does Exim also come with a nice mailing list that doesn't demand the exile of people with dissenting opinions? ---Kris Kelley
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes on 15 January 2001 at 15:55:50 -0500 David Dyer-Bennet writes: I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. I think this is a very bad idea. My primary reason is that it's easier to apply a patch against updated main code than it is to integrate the changes from that updated main code into a standalone program. If Dan was putting out daily versions of qmail, sure. But we've had qmail-1.03 for several years now. Also, some things are much better implemented as a change to the existing programs, rather than as an additional layer of programs. Try applying two patches to the same program. Some days it works better than other days (well, actually it's not the *day* that makes it different). I've worked professionally in software development for 30 years; sometimes you just have to slog through things like that. If I were dealing with the problem based on a separate derived program, and a new release of the original, I'd end up approaching it by using diff to essentially make patches of the differences. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
Piotr Kasztelowicz [EMAIL PROTECTED] writes on 15 January 2001 at 22:08:50 +0100 Hello Perhaps then the only change necessary is to change the semantics of the qmail.org site? Instead of "so-and-so has written a patch to...", change it to "addition" or "add-on" or whatever. Qmail ver 1.03 does not already "young" software. How about to suppose Dan to make the new version - perhaps made with cooperation with all peoples, who have created useful patches and additional softwares, so that this all will be included to new version? A number of the patches are to implement functionality discussed with Dan on the list, which he rejects the utility of. I think we can safely presume that the patches will NOT in general be incorporated into a new release. (Not that Dan is completely opposed to incorporating ideas or code from other people; he has done some of that already.) -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
Felix von Leitner [EMAIL PROTECTED] writes on 15 January 2001 at 22:17:41 +0100 Thus spake David Dyer-Bennet ([EMAIL PROTECTED]): Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. A "patch" is also a recognized way to make an upgrade. The word "upgrade" also implies that there is something wrong or inferior with the original qmail. At some level we can't get around it; after all, the fact that we want to make some change to qmail suggests that the original code doesn't perfectly meet our needs. "Upgrade" suggests adding features, rather more than "patch" does; patches are often released to fix bugs. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
From: "David Dyer-Bennet" [EMAIL PROTECTED] Date: Mon, 15 Jan 2001 15:38:18 -0600 (CST) Felix von Leitner [EMAIL PROTECTED] writes on 15 January 2001 at 22:17:41 + 0100 Thus spake David Dyer-Bennet ([EMAIL PROTECTED]): Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, tha t implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. A "patch" is also a recognized way to make an upgrade. The word "upgrade" also implies that there is something wrong or inferior with the original qmail. At some level we can't get around it; after all, the fact that we want to make some change to qmail suggests that the original code doesn't perfectly meet our needs. "Upgrade" suggests adding features, rather more than "patch" does; patches are often released to fix bugs. How about "addition" or "extension"? Chris -- Chris Garrigues http://www.DeepEddy.Com/~cwg/ virCIO http://www.virCIO.Com 4314 Avenue C Austin, TX 78751-3709 +1 512 374 0500 My email address is an experiment in SPAM elimination. For an explanation of what we're doing, see http://www.DeepEddy.Com/tms.html Nobody ever got fired for buying Microsoft, but they could get fired for relying on Microsoft. PGP signature
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes: Try applying two patches to the same program. While this may require some manual reconciliation between conflicting packages, it's far better than needing a seperate full distribution of components of qmail for every possible combination of patches. For example, if there are 10 different patches against qmail-smtpd, then there are 1,024 different packages that would have to be available to support the various combinations of patches. Worse, as more patches come out, this number increases exponentially. If I come out with yet another patch to qmail-smtpd, all of a sudden we're up to 2,048 packages. And who is responsible for generating the additional 1,024 packages, me or the first 10 developers? If the 10 different packages are all maintained by different people, let's say A-J, obviously A is responsible for making qmail-smtpd-A available, and B for qmail-smtpd-B. But is A or B responsible for qmail-smtpd-AB? And what if A thinks B is an idiot, and B thinks A is? Either a third party will have to create qmail-smtpd-AB, or else an end user who wants qmail-smtpd-AB will be responsible for putting it together, probably by downloading all of the packages, producing patches with diff, and applying to the original qmail sources. Further, the base qmail source is well-tested. It's easy to see exactly how much is changed by a patch, and if there are problems, to investigate only those areas which a patch affects. With a full package, to isolate problems to just the patch's changes will require you to download the original and the modified version, and use diff to compare the changes, essentially giving you a patch file. Still further, patches which touch multiple parts of qmail (such as the ETRN patch) would require basically a redistribution of all of qmail, which would make the exponential patch growth problem even worse. And still further yet, it's not even clear that qmail's distribution terms allow this, without getting explicity permission from the author for each new package: DJB If you want to distribute modified versions of qmail DJB (including ports, no matter how minor the changes are) you'll DJB have to get my approval. This does not mean approval of your DJB distribution method, your intentions, your e-mail address, DJB your haircut, or any other irrelevant information. It means a DJB detailed review of the exact package that you want to DJB distribute. (from http://cr.yp.to/qmail/dist.html) If explicit permission is required for each new package, it would make the time required to produce a patch higher, which would discourage people from producing patches or packages. I think that the way it works now is the best it can currently be. A better option is to take all of the common qmail patches, and produce a new qmail package with them applied or available as options. This would mean that more obscure patches could be against this package, reducing the chance of conflicts, and that the package with modifications would be well-tested. This, I believe, is similar to the situation with ezmlm-idx. --ScottG.
RE: A firestorm of protest?
If Dan was putting out daily versions of qmail, sure. But we've had qmail-1.03 for several years now. Isn't that really the root of the problem? They aren't patches, they're features. But for whatever reasons, the main sources are never updated to reflect greater capabilities. (Which probably means that someday, someone will come out with a secure open-source MTA that accepts and rewards coders by integrating patches, and qmail will slip into history.) -- gowen -- Greg Owen -- [EMAIL PROTECTED] SoftLock.com is now DigitalGoods!
Re: A firestorm of protest?
At 01:18 PM 1/15/2001, Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. I love the patches. I like being asked to add a certain functionality to the email server, hitting qmail.org, pressing crtl+f and finding the way to provide that functionality to my current installtion. I keep my "patched" source in a directory structure in anticipation of the next added feature that my boss asks for. I'm comfortable that I won't have to recompile from the top, adding every slice of "improvement" to my qmail all over again. I think it's a great resource, and since I've never said it before, thanks for hosting it and keeping it alive over there. I only go there when I need it, btu when I do I'm grateful that it's there. I never got the implication that qmail was somehow flawed because there were all these "patches" to the code. Rather I enjoyed the fact that I had downloaded and installed a fundamental email server to which I could add the functionality I needed and nothing more. If you do remove the patch section (please don't) then please send out a warning so I can download local safe copies of every patch against the day when I might need them. I say, keep the status quo. It's beautiful, don't change a thing. Jerry Lynde, Devoted qmail Advocate
Re: A firestorm of protest?
Scott Gifford writes: Russell Nelson [EMAIL PROTECTED] writes: Try applying two patches to the same program. While this may require some manual reconciliation between conflicting packages, it's far better than needing a seperate full distribution of components of qmail for every possible combination of patches. Don't be ridiculous. Instead of producing a different package, you would send the patch to the author of the enhanced qmail-smtpd. If he refused to accept it, then you might consider creating your own package. And still further yet, it's not even clear that qmail's distribution terms allow this, without getting explicity permission from the author for each new package: That's why I want to find the email message where Dan gave us permission to reuse parts of qmail. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: A firestorm of protest?
Felix von Leitner wrote: I'd rather see www.qmail.org be changed so that you would have to click through a banner page that clearly states that none of those patches is necessary to make qmail any more secure, more reliable or faster. Please don't cripple my work with qmail in the vain attempt to make stupid people understand. They won't. That's why they are stupid in the first place. Russ, if you desire, please put a few explaining words over the patch section, and then proceed to ignore the idiots. It will make your life easier and the idiots will die out or move back to Exchange and it will save all of us a lot of stress. +1 Greg Felix
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes: Scott Gifford writes: Russell Nelson [EMAIL PROTECTED] writes: Try applying two patches to the same program. While this may require some manual reconciliation between conflicting packages, it's far better than needing a seperate full distribution of components of qmail for every possible combination of patches. Don't be ridiculous. Instead of producing a different package, you would send the patch to the author of the enhanced qmail-smtpd. If he refused to accept it, then you might consider creating your own package. It's not that ridiculous. Say you have patches to qmail-smtpd to support SSL/TLS via 'STARTTLS', to support 'ETRN', and to support the SMTP AUTH extensions (these patches probably exist, and I don't know how they're organized, so let's just use them as examples). Users could want any combination of these features, exclusive of any others. Either you combine them all into one package that supports all 3, or you need 8 different packages to support any possible combination. If you combine all common patches into one "uber-patch", then you're essentially producing a new version of qmail which is much larger and has many more features than Dan's. Some people will see this as progress, others as bloat. Personally, I think this is probably a good idea, as long as things are well-tested. Otherwise, you end up with exactly the exponential package growth I described in my previous message. -ScottG.
RE: A firestorm of protest?
Hi Russ, I'd like to add my voice to the firestorm too... I've found a couple of places where Dan decries patches: http://msgs.securepoint.com/cgi-bin/get/qmail9812/214/1/2/1/3/2/1/2/1.html (which says at the end) DJBYou are of course free to distribute patches---but you're hurting the community DJBwhen you do it. Patches are a support nightmare, to the extent that they're DJBactually used; and they make it much more difficult for the author to find out DJBwhat the users actually want. I have a lot of sympathy for that view, given that Dan gave us qmail! At the same time, people are doing things with qmail to make it work in their weird corporate setups, or for fairly specific tasks, for which qmail is not designed, nor is it likely to move in that direction. It's important that qmail can be deployed in these places as well as "Ordinary" setups, since qmail's kudos and spread is enhanced. I would also like to mention one of Dan's pages on legal rights, which specifically mentions patches... According to the CONTU Final Report, which is generally interpreted by the courts as legislative history, ``the right to add features to the program that were not present at the time of rightful acquisition'' falls within the owner's rights of modification under section 117. (that's an extract, there's more). The URL for this is, http://cr.yp.to/softwarelaw.html Because a patch implies that something is wrong, and needs to be fixed. For some people yes, but as others have replied, some rewording of the patches section may minimise this impression - as well as helping most of the readers of qmail.org who are the sysadmins running qmail, sometimes needing a particular tool or patch - and qmail.org is a brilliant central repository for them. As most people on the qmail list will be aware, there are some peculiar setups out there, and according to local needs and policies, different add-ons will be needed. I feel patches are the best way to provide these: They tend to be small and to-the-point. They also require some tech expertise to use, but if people are running qmail in anger ( = "Real world scenarios"), they hopefully have this tech expertise to start with - if not, it's not the fault of you as qmail.org maintainer. When I have a strange requirement, the first place I look is qmail.org, followed by the archives - to ensure I don't re-invent the wheel. What you've given us, the qmail community, with qmail.org is a resource that helps us to avoid exactly that - it's good to see what other people do to integrate qmail into their qmail-hostile environments. Without those itsy-bitsy patches, a lot of people would be stuck, not really knowing if they can get qmail working (perhaps modified) in their particular setup. I think there is a case for some reworking of the qmail.org page - specifically to increase the prominence of the first few paragraphs, perhaps some bullet points for the source / mailing list / archive: At present a [too] casual reader may just skim through these paragraphs, not realising how important the links they provide are, and reach instead the boxed text areas, which are more visually catchy. (I volunteer myself for a sample reworking if this is desired). Regarding Dan's specific comments about authors trying to work out what users want (see above): From time to time on the list there is a "Wish list for qmail", which normally bogs down in fairly tech-y discussions. Maybe Dan could comment on whether he would consider producing a new version of qmail to incorporate some of the things on www.qmail.org - presumably some would be as "Options". If he has that interest, I'm sure the list would be only too interested to offer their opinions on which "Options" would be most desired - and people on the list might also contribute to a group effort to knock some of these "Options" into better shape (the quality of patches and add-ons is variable), so that Dan would have cleaner/tighter source to base his work on (and presumably it'd be in C rather than Perl - so some of the Perl add-ons would need "Translation"). Maybe you could raise this idea with Dan, if he's not listening in on this discussion already... Whatever you decide, thank you for providing and maintaining www.qmail.org - it's where I caught the qmail bug in the first place, and I haven't looked back since. Please don't do it cheers, Andrew.
Re: A firestorm of protest?
On Mon, Jan 15, 2001 at 03:18:10PM -0500, Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. I'd just rename it from patches to "additional functionality" or something like that. -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany
Re: A firestorm of protest?
Hello qmailers :-) Let's just leave it as it is and if you want to call them something, then qmail non-standard extensions. I'm sure Dan is concerned that these extensions can introduce security concerns, not because of your programming, but the environments they will be working in/with. Perhap's he feels this could reflect on qmail's good name, or the multitude of associated doc's can confuse and fragment, something he is keenly aware of. That's why (ideally) he wants everything installed in exactly the same locations no matter what Un*x version it's installed on. What caused this rumpus anyway ? Regards...Martin -- --- 2 Watch. How if a' will not stand? Dogb. Why, then, take no note of him, but let him go; and presently call the rest of the watch together, and thank God you are rid of a knave. -- William Shakespeare (1564-1616), Much Ado about Nothing -- Act iii, Sc. 3
Re: A firestorm of protest?
On Mon, 15 Jan 2001, Felix von Leitner wrote: If you want to use bloated, unreliable, immensely fat software with a Where I have written, that EACH patch? Only USEFUL patch. The world goes forward! Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: A firestorm of protest?
On Mon, 15 Jan 2001, Scott D. Yelich wrote: See, these things that are really needed to get any use out of qmail, aren't supported... won't be supported, etc., as they make qmail less This should be Dan's decision. I don't apply to sugest, but I suppose there are group of Dan's friends, group of advanced users, who known very good qmail as well as Dan personaly. Qmail is the best known by me MUA, so I will by happy, if it were progress ... Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: A firestorm of protest?
On Tue, 16 Jan 2001, Piotr Kasztelowicz wrote: This should be Dan's decision. I don't apply to sugest, but I suppose there are group of Dan's friends, group of advanced users, who known very good qmail as well as Dan personaly. Qmail is the best known by me MUA, so I will by happy, if it were progress ... Ditto. There's enough goodness to overlook the any minor irritations and lameness. Scott
