Re: Why Red Hat is not distributing qmail
Rask Ingemann Lambertsen [EMAIL PROTECTED] writes on 13 January 1999 at 02:52:50 +0100 On 04-Jan-99 17:12:52, Dave Sill wrote something about "Re: Why Red Hat is not distributing qmail". I just couldn't help replying to it, thus: [EMAIL PROTECTED] wrote: In some situations Qmail is less efficient than sendmail, and its performance is sorely lacking. Every complex system has weaknesses. Which is a poor excuse for at least some of qmail's weaknesses. Qmail does not verify envelope sender addresses, right out of the box. Nor should it. The bounce mechanism works. It does? Then perhaps it is qmail that is broken? Because I sure see lots of double bounces. I, also, would prefer not to accept email with bogus sender addresses, because of the double-bounce problem. However, *if* envelope sender checking becomes common, then spamming software will simply send everything with no envelope sender -- which we're obliged to accept since that's bounce message format. Or they'd forge something else valid. And checking the sender is fairly expensive, too. Checking the sender would provide a little bit of extra help right now, but it wouldn't last long. It's no long-term answer to spam. It's easy to work around once spammers realize it's being checked. Qmail does not support RBL, right out of the box. Nor should it. There's an add-on to do that. RBL support, these days, in a world that isn't as perfect as qmail was designed to view it, is not an option, but rather a requirement. Out of the box. But as long as you are not allowed to distribute such a setup, there is little point in discussing it. I'm running RBL with qmail, and it was perfectly simple to install (I'm using rblsmtp). According to my logs, it blocks fewer spam messages than get through to my account alone. While I approve of the RBL, and have seen it do good (both Panix and the University of Minnesota have changed policies and done cleanup work to halt their use as an open relay shortly after discovering they'd made the RBL), I hardly consider it a necessity for any system. It actually blocks only a small fraction of the spam trying to get to me. -- David Dyer-Bennet [EMAIL PROTECTED] http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon http://ouroboros.demesne.com/ The Ouroboros Bookworms Join the 20th century before it's too late!
Re: Why Red Hat is not distributing qmail
[EMAIL PROTECTED] writes: | And checking the sender is fairly expensive, too. And yet, you have to check eventually, because you'll be attempting to send a bounce there in a few seconds.
Re: Why Red Hat is not distributing qmail
Sam [EMAIL PROTECTED] writes on 13 January 1999 at 16:12:49 GMT [EMAIL PROTECTED] writes: And checking the sender is fairly expensive, too. No it's really not. You've got a caching name server on the local net, right? Yes; but it's not that likely that I've got the sender's domain already cached. It's probably an actual additional DNS lookup. -- David Dyer-Bennet [EMAIL PROTECTED] http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon http://ouroboros.demesne.com/ The Ouroboros Bookworms Join the 20th century before it's too late!
Re: Why Red Hat is not distributing qmail
On 04-Jan-99 17:12:52, Dave Sill wrote something about "Re: Why Red Hat is not
distributing qmail". I just couldn't help replying to it, thus:
[EMAIL PROTECTED] wrote:
In some situations Qmail is less efficient than sendmail, and its
performance is sorely lacking.
Every complex system has weaknesses.
Which is a poor excuse for at least some of qmail's weaknesses.
Qmail does not verify envelope sender addresses, right out of the
box.
Nor should it. The bounce mechanism works.
It does? Then perhaps it is qmail that is broken? Because I sure see lots
of double bounces.
Qmail does not support RBL, right out of the box.
Nor should it. There's an add-on to do that.
RBL support, these days, in a world that isn't as perfect as qmail was
designed to view it, is not an option, but rather a requirement. Out of the
box. But as long as you are not allowed to distribute such a setup, there is
little point in discussing it.
Qmail's logging is virtually nonexistent.
Wrong. qmail-smtpd's logging is minimal,
No, it is non-existant.
but qmail's logging, in general, is quite adequate.
It is, in general, quite adequate for performance monitoring. When it
comes to helping the postmaster find and possibly correct problems, it leaves
something to be desired. Here are some of the less useful error messages that
spring to my mind right now:
Sorry, unable to establish an SMTP connection.
This one is similiar to the classic "unable to open file" with no mention
of the file name, except you get two for the price of one. Not only does it
not mention which server it tried to connect to, it also doesn't mention why the
connection couldn't be established. The postmaster can always try out each
errorcode from errno.h in turn and see which fix starts the mail flowing.
Sorry, homedir is writable.
This is a candidate for the "Obfuscated MTA Error Message of the Year"
award. Of course the homedir is writable, how else would you deliver the
mail? So the postmaster can waste valuable productive time needlessly digging
through documentation so that qmail-local can be strlen("group or world ")
bytes shorter.
CNAME lookup failed temporarily.
Only two addresses to guess from. Wauw, 50% chance of guessing the right
one in your first attempt. Of course qmail knows which one it is, but it
won't tell you. No need to be helpful to the postmaster.
Certain things Qmail can do better than sendmail, but there's still a lot
of functionality that many people want, and Qmail does not have, unless
you go out and grab a bunch of other software as well.
Modularity.
Some people would find a search-and-replace module for a text editor
taking modularity beyond a reasonable level. I'm one of those people.
Modularity doesn't prohibit you from putting together a set of modules
nicely integrated with the base package.
[cut]
DJB is making demands that nobody else in the entire world is
making, and, no matter how good Qmail is, I do not see why it is so
special that it needs it.
Dan doesn't need to justify his actions to you or anyone else
here. The fact is that he owns qmail, and he can redistribute it under
whatever terms he chooses. He's explained his rationale.
Most of it. I'm still waiting for the rest, but I'm not holding my breath
and I'm past the point where it would make a difference.
I've tried to restate it.
Which is completely pointless, IMHO. When Dan says someting (as opposed to
just sending streams of words to the list), he's usually very clear. No
ambiguities.
Regards,
/¯¯T¯\
| Rask Ingemann Lambertsen | [EMAIL PROTECTED] |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC |
| Do artificial plants need artificial water? |
RBL - Was Re: Why Red Hat is not distributing qmail
I have to agree with John. I like using the RBL, I find it to be somewhat effective in blocking some spam, but I do *not* think it should be hard-coded into the MTA. What if for some reason in the future I decide I do not want RBL anymore? Right now I can just delete part of my tcpserver line and restart qmail. I suppose you could add an option whether or not to use the RBL, but then you're adding unnecessary code into qmail which works just as well as an add-on. --Adam - Original Message - From: [EMAIL PROTECTED] To: qmail mailing list [EMAIL PROTECTED] Sent: Tuesday, January 12, 1999 10:11 PM Subject: Re: Why Red Hat is not distributing qmail On Wed, Jan 13, 1999 at 02:52:50AM +0100, Rask Ingemann Lambertsen wrote: Qmail does not support RBL, right out of the box. Nor should it. There's an add-on to do that. RBL support, these days, in a world that isn't as perfect as qmail was designed to view it, is not an option, but rather a requirement. Out of the box. But as long as you are not allowed to distribute such a setup, there is little point in discussing it. I use qmail to deliver intranet mail. Why do I need RBL? In general, why should the MTA writer be able to dictate what anti-spam measures I am and am not taking? -- John White [EMAIL PROTECTED] PGP Public Key: http://www.triceratops.com/john/public-key.pgp
Re: Why Red Hat is not distributing qmail
[EMAIL PROTECTED] wrote: On Wed, 30 Dec 1998, Dave Sill wrote: Let me try again. Licensing alone could conceivably explain why Red Hat doesn't ship qmail. But it does't explain why they don't ship exim, smail, zmailer, or any other OSS sendmail equivalent. So, there has to be another reason, that's all. It is probably the same reason why these MTAs have virtually no market share of any kind. Inertia. "Sendmail is good enough." No, the question is very specific: if Red Hat botched the sendmail RPM, how does that sole event somehow translate into Eric Allman's reputation being affected in any way? The answer, of course, is that it doesn't. The answer, of course, is that it *does*. First, Allman will be guilty by association. Lots of people know that he wrote sendmail. If they hear about a sendmail problem, without complete details, they'll naturally assume he's responsible. Second, by allowing other people to modify and repackage sendmail, he's implicitly saying that he doesn't care what people do to it, even if they break it. That's one difference between Eric, Wietse, and all the other OSS authors and Dan: Dan's not willing to let other people diddle with his code. Since I've been reading the mainstream press quite extensively lately, I'm comfortable to say that this is not going to be the case. Doesn't matter. Nothing you think will change Dan's mind. You are replying to the assertion that complaining to the author - when a vendor's packaging breaks - would be stupid. Maybe I got confused. Complaining to the vendor/packager would be smarter than complaining to the author, but there's no mechanism to ensure that all complaints go to the right place. Of course not. But victims of these third party changes will surely go to him or his lists for help. No. That's my point. The victims will be going back mostly to the vendor. This is not an arbitrary claim, but it's based on experience over the last couple of years. "mostly" Maybe you find that acceptable. I postulate that Dan doesn't. And these victims will also be unaware of the changes their vendor made, so the help they get might be wrong. Oh yes they will _certainly_ be aware. That's because they installed a vendor-specific file in the first place. Oh, right, users installing, say, a broken modified qmail RPM will *know* that the packager broke it, not the author. I forgot that. There will be unnecessary confusion in the support community, and this confusion will reflect poorly on Dan and his products to casual observers who don't realize that the confusion is due to third party diddling. This is plainly FUD. FUD, FUD, FUD... Huh? If that's true, Brister would've never had the time to write inn 2.0, because he would've been handling all the mail from Red Hat users. There was a whole bunch of people out there who suddenly discovered that they can simply load the Red Hat CD, and instantly have a server on their hands that can handle a full Usenet feed. Up until that point, you needed to have a pretty good INN hacker on staff in order to accomplish that. You clearly think OSS, Red Hat, and RPM's are the key to mankind's salvation. Good for you. It's just as clear, however, that Dan doesn't agree, and repetively claiming that you're right and he's wrong isn't going to change his mind. In some situations Qmail is less efficient than sendmail, and its performance is sorely lacking. Every complex system has weaknesses. Qmail does not verify envelope sender addresses, right out of the box. Nor should it. The bounce mechanism works. Qmail does not support RBL, right out of the box. Nor should it. There's an add-on to do that. Qmail does not support UUCP, right out of the box. Nor should it. It's an SMTP server, not a multiprotocol mail gateway. Qmail does not rewrite headers on relayed mail, right out of the box. Nor should it. There's an add-on to do that. Qmail can't even handle any kind of a reasonable load, right out of the box. You have to go back and install tcpserver for that. For those whose inetd's can't be configured to allow higher connection rates, yes, tcpserver is required. Big deal. Qmail's logging is virtually nonexistent. Wrong. qmail-smtpd's logging is minimal, but qmail's logging, in general, is quite adequate. Certain things Qmail can do better than sendmail, but there's still a lot of functionality that many people want, and Qmail does not have, unless you go out and grab a bunch of other software as well. Modularity. You will not find any single OSS package that comes with any operating system in the same original form that the OSS package is distributed by the author, period. Besides an MTA, there are other software out there that's just as vital to the overall system security. Their respective authors do not appear to have any difficulties allowing commercial distributors to reconfigure the software for their specific operating system.
Re: Why Red Hat is not distributing qmail
This'll be my last word on the topic. OK, stop cheering. :-) [EMAIL PROTECTED] wrote: On Mon, 4 Jan 1999, Dave Sill wrote: Question: *Why doesn't* Red Hat ship zmailer, exim, smail, or any other OSS sendmail equivalent? Because they are not as well tested don't scale and do not offer a functional replacement for sendmail. I told you that before, but, you chose to ignore it. If you said that, I missed it. Sorry. I'm a big qmail fan, but even so, I'm pretty sure it's not the only viable sendmail replacement. I'm not interested in arguing this point, though. How about if we just let developers who don't want to make their code OSS set their own terms based on their beliefs and desires? You're dodging the issue. You are claiming that OSS development framework is somehow defective (in the previous statement of yours that you conveniently left out). I'm arguing that Dan finds the OSS model inadequate to protect qmail to his level of comfort. I "conveniently" left it out because I didn't see any reason to include it. Now that I've asked you to explain the defects in well-known OSS products, you're suddenly changing the topic to something else. Personally, I'm an OSS fan, and have been for many years--at least 10 years before the term "Open Source Software" was coined. A lot it of it is very good. I shudder to think how I'd do my job if I woke up one day and it all was gone. A good bit of it is crap, too, but I'm able to detect and avoid it pretty easily. But I've never seen any OSS that I'd put in the same class as djbware. If Dan feels the need to restrict diddling of djbware, that's OK with me. I don't care if Red Hat or Debian or OpenBSD switch to qmail. As long as I can install it wherever I need it, and diddle with my own copies as I need to, I'm perfectly happy. Just because OSS works for some developers/projects, doesn't mean it's the only valid model. Well, then, please explain what is so special about Qmail that requires something different. The answer is: nothing. I believe its extraordinary quality and security sensitive nature justify its restricted distribution. You may acknowledge it as simply a privilege reserved by the author; but you will not be able to claim that there is any good and sound technical reason for it. Any time this question is put to you, you keep repeating the same mantra about diddling with the code. Code quality control is a good, sound technical reason. Well, diddling with the code doesn't bother those who maintain the infrastructure that the Internet runs on. Maybe it should. Maybe it would if their code was as tight as qmail's. Just because OSS is good enough to run the Internet doesn't mean it's appropriate for everything. Next time you have a CAT scan, ask yourself if you'd like the software running the scanner to be Open Source, running under Red Hat Linux, installed from some RPM that the technician found on the net, or tightly controlled, tested, audited code provided by the manufacturer, running on tested, approved, h/w and OS. qmail is not a democracy. Once again, you're changing the topic. Noone said that it has to be a democracy. Try arguing the topic, for a change. My point is that 5,000 people screaming at Dan for relaxed qmail redistribution rights won't mean squat. Dan has already considered relaxed licensing, already heard and considered all of your arguments, and decided against it. Deal with it. Oh, right, users installing, say, a broken modified qmail RPM will *know* that the packager broke it, not the author. I forgot that. Too bad, because they do. You can choose to ignore that fact, but it will remain a fact nevertheless. Riiight. But even if I agreed, it wouldn't matter. Well, facts matter to me. Then you should realize that your "fact" isn't one: it's an assertion. And since add-ons cannot be redistributed, Wrong. You cannot redistribute Qmail with add-ons, silly. You can't distribute modified qmail source or binaries, but you can distribute virgin qmail + add-ons like rblsmtp and you can distribute virgin qmail source + source patches for add-ons. Now who's being silly? Ever heard of rblsmtp? Which is badly broken, That's news to me, but I don't use it. and places unnecessary load on the server, and In your opinion. does not permit selective RBLing based upon the recipient. procmail. Modularity. Sure, it's less efficient, in some ways. "Premature optimization is the root of all evil." Fine. Let's just say that qmail requires tcpserver. So what? So what is the fact that Qmail is not the ultimate MTA, therefore, if you choose to argue that a vendor must bend through hoops in order to distribute it, just because it's so great, you will be mistaken. I'm not a vendor, but if I was, I *would* jump through hoops to distribute qmail. It's not "ultimate", as if that's possible, but it's the best there is for the types of applications I have. Except that qmail-smtpd logging is what
Re: Why Red Hat is not distributing qmail
But I've never seen any OSS that I'd put in the same class as djbware. I have. Just because OSS works for some developers/projects, doesn't mean it's the only valid model. Well, then, please explain what is so special about Qmail that requires something different. The answer is: nothing. I believe its extraordinary quality and security sensitive nature justify its restricted distribution. Its security sensitive nature is no different than the same security sensitive nature that other MTAs have to deal with, and there does not appear to be any problems with their distribution method. As far as quality goes, I've seen better, and I've seen worse. You may acknowledge it as simply a privilege reserved by the author; but you will not be able to claim that there is any good and sound technical reason for it. Any time this question is put to you, you keep repeating the same mantra about diddling with the code. Code quality control is a good, sound technical reason. Code quality has nothing to do with the distribution method. You have a lot of secure, quality, software out there being distributed as OSS. Well, diddling with the code doesn't bother those who maintain the infrastructure that the Internet runs on. Maybe it should. Maybe it would if their code was as tight as qmail's. Again, please substantiate your implicit assumption that it isn't. You are making a straw argument. Just because OSS is good enough to run the Internet doesn't mean it's appropriate for everything. Next time you have a CAT scan, ask yourself if you'd like the software running the scanner to be Open Source, running under Red Hat Linux, installed from some RPM that the technician found on the net, or tightly controlled, tested, audited code provided by the manufacturer, running on tested, approved, h/w and OS. I'd feel more comfortable with a product that has undergone an extensive peer review and anal exam, as compared to some closed box that only the manufacturer knows how it works. Once again, you're changing the topic. Noone said that it has to be a democracy. Try arguing the topic, for a change. My point is that 5,000 people screaming at Dan for relaxed qmail redistribution rights won't mean squat. Dan has already considered relaxed licensing, already heard and considered all of your arguments, and decided against it. Deal with it. Feel free to point out any time in the past where I have actually argued that. I have not. I don't care. I'm simply debunking the baseless claim that there is any sound reason behind the restrictions on the distribution. There aren't any. It's simply personal privilege, nothing else. Why don't *you* deal with the fact that there's no valid reason for a restrictive distribution license, except personal privilege. Oh, right, users installing, say, a broken modified qmail RPM will *know* that the packager broke it, not the author. I forgot that. Too bad, because they do. You can choose to ignore that fact, but it will remain a fact nevertheless. Riiight. But even if I agreed, it wouldn't matter. Well, facts matter to me. Then you should realize that your "fact" isn't one: it's an assertion. Of course, you've written OSS that vendors have packaged for distribution, and you have first-hand experience in making that conclusion. And since add-ons cannot be redistributed, Wrong. You cannot redistribute Qmail with add-ons, silly. You can't distribute modified qmail source or binaries, but you can Right. distribute virgin qmail + add-ons like rblsmtp and you can distribute virgin qmail source + source patches for add-ons. Which is what - 5-10% of all the add-ons? Ever heard of rblsmtp? Which is badly broken, That's news to me, but I don't use it. Neither do most of the people who have implemented RBL checking (by other means). and places unnecessary load on the server, and In your opinion. Is how the actual code works just my opinion? Is it only my opinion that rblsmtpd returns a temporary error code, for no good reason, so that the blacklisted relay keeps banging at your server for two weeks, until the mail bounces? As opposed to every other RBL implementation out there, which immediately rejects all mail? does not permit selective RBLing based upon the recipient. procmail. Modularity. Sure, it's less efficient, in some ways. It would also be broken. We are not talking about user-level filtering, but system-level filtering. Furthermore, post-receipt filtering opens up your server as a conduit for certain denial-of-service attacks. Anyone who actually done any kind of work or research in that area knows it. "Premature optimization is the root of all evil." So is a broken spam filter. So what is the fact that Qmail is not the ultimate MTA, therefore, if you choose to argue that a vendor must bend through hoops in order to distribute it, just because it's
Re: Why Red Hat is not distributing qmail
"Peter C. Norton" [EMAIL PROTECTED] wrote: Only part right. Those I've talked to at redhat say that they give their work back to the community, and for free, because they believe it's a valid business model, but also because it makes them feel good. They were and are bucking the pointy-haired trend in the computer world. A big part of it is because what they're doing makes them feel good. OK, granted. But Red Hat is more than the handful of techies you've talked to. It's a business entity that exists independently of any of its employees. It's got strategic and equity partners such as Intel, Netscape, and a couple venture capital firms. Regardless of the altruism of the employees, these partners have significant influence in how Red Hat does business. If Red Hat was a bunch of geeks dedicated to furthering the hacker ethic, replacing sendmail with qmail or even postfix or exim would be a no-brainer. They'd evaluate the choices, pick a winner, and do whatever it would take to implement the switch. I disagree. The choices are more then technical, because Dan makes it so. Such choices are *always* more than technical. But, yes, qmail's licensing makes it harder for Linux packagers to include than less restrictively licensed MTA's. My point here is that Dan's restictions are not insurmountable. There are no legal or technical reasons why qmail--even binary distributions--couldn't be distributed with Linux. The executives will want to be sure that the costs of switching are lower than the benefits of switching--otherwise they'll lose some of their precious growth or profits. I disagree again. If it was viable for them to offer qmail as a replacement beyond the technical considerations (and Dan has gone to alot of trouble so that there aren't any technical considerations in the simplest cases) then they would. So what else is there? Sounds like either a personality clash or a refusal by Red Hat to include software they can't diddle with. I'm soundly opposed to the picture you paint of linux or other free OS' being monolithic inflexible distributions. Oppose all you want. It's naïve to think of RHL as some kind of altruistic, cooperative effort with unlimited resources to support multiple alternatives to large, complex subsystems like MTA's. ... If your POV (as I read it) that the motivating reason redhat doesn't do this is because they're a pointy-haired business was at all accurate then all non-pointy-haired OS distributions should have qmail, right? Firstly, I don't know what you mean by "pointy-haired". My contention is that there are no legal or technical reasons that RH couldn't offer qmail with RHL. Further, RH is a business, and any decision regarding qmail would, at least in part, be a business decision. I don't think Red Hat is evil because they're commercial, I just realize it impacts their decisionmaking. Well, where is qmail? I see wu-ftpd being replaced by proftpd in places, I see apache installed instead of CERN or NCSA httpd, I see gnu utilities instead of BSD utils, or where appropriate BSD utils instead of GNU utils, I see network code getting tightened up, kernels being scrutinized, but I don't see qmail anywhere. What's the answer? Obviously licensing is a factor, but I still think inertia is a bigger part of it. If qmail replaced sendmail as transparently as any of your examples above replace their counterparts, I think we'd see a lot more qmail. Then why haven't any of the other many free operating system distributions moved towards qmail? Ask them. Red Hat demands the right to fiddle with the code. I asked the OpenBSD folks about it a long time ago and their response was that they weren't sure qmail was free (this was pre-1.0) and that sendmail had a lot of inertia. -Dave
Re: Why Red Hat is not distributing qmail
What I do not get is why RH does not have an "unusual" section where they would distribute software that does not fit their distribution policies---similarly to debian's "nonfree" section. Then they could distribute a qmail src rpm. Mate
Re: Why Red Hat is not distributing qmail
On Wed, Dec 30, 1998 at 03:31:00PM -0500, Dave Sill wrote: Let me try again. Licensing alone could conceivably explain why Red Hat doesn't ship qmail. But it does't explain why they don't ship exim, smail, zmailer, or any other OSS sendmail equivalent. Let's suppose that aside from licensing that qmail is the only MTA that provides enough of a convincing improvement to consider knocking sendmail out of a distribution. It's more cleanly designed then exim, more secure then smail, more stable then zmailer, and faster then the others (by far in my experience). That could be why none of the others ship. This is absurd. Would Eric Allman's reputation be "on the line" if Red Hat broke their sendmail package? Trick question, right? Should I answer "No. Eric already trashed his own reputation with sendmail" or "Yes. Whatever little reputation he's regained by the recent sendmail bug drought would vanish"? *cough* He's got a great reputation in the press and at the executive level. He's the name that's associated with sendmail, sendmail is publicised as running "75% of the mail on the internet" right? I think his code and mailer is shoddy, but his reputation in the wider world seems to be completely unconnected with the security, speed, or reliability* of the software he's written. A lot of people use and like sendmail. Probably a lot more then the number of people who've deployed qmail. [...] The notion that any individual author would get the flack for a broken distribution is rather silly. Silly things happen all the time. See above re: sendmail and allman. Who told djb that he'll have to support third party changes? Nobody told him that. Of course not. But victims of these third party changes will surely go to him or his lists for help. And these victims will also be unaware of the changes their vendor made, so the help they get might be wrong. True. Is that so bad? The list and djb get a lot of mail already. New users have questions that need to be answered no matter what their method of installation. All a standard, even broken distribution really changes is that the question becomes a FAQ almost immideatly, and can be answered simply and thoroughly. There will be unnecessary confusion in the support community, and this confusion will reflect poorly on Dan and his products to casual observers who don't realize that the confusion is due to third party diddling. I think you're overstating the problem. If you have a repeatable problem because of a single change that is installed everywhere it becomes almost a non-issue. Just a nuisance, not a real problem. Does this mean that James Brister is responsible for supporting all of the stuff that Red Hat puts into inn-1.7.2 RPM? Nobody's holding a gun to head and making him answer them, but, yes, Brister has to deal with whatever gunk is in the RPM because he's going to get questions about it. Dan seeks not to burden himself with whatever frivilous changes the vendor wants to make to qmail. Why all of the negativity? I think a package author would be happy that he stops getting FAQ's in his mailbox because a lot of nifty things are included in the package that users always ask him and/or inn mailing lists for, and that cuts down on the traffic. Maybe it evens out or tips the balance towards the package reducing irrelevant traffic. Huh? How about improved performance, efficiency, security, and functionality? Or did those evaporate because Dan won't let Red Hat diddle the code? It hasn't improved over itself much since 1.00, so the reasons probably haven't changed since their last evaluation, which was negative. -Peter
Re: Why Red Hat is not distributing qmail
It hasn't improved over itself much since 1.00, so the reasons probably haven't changed since their last evaluation, which was negative. qmail itself hasn't had terribly major changes, but a lot of things have been added along side qmail which make it much more attractive, such as dot-forward, fastforward and rblsmtpd, as well as the ability to deliver to /var/mail via the local mailer (OK, it could always do that, but Dan now ships samples that use mail.local and procmail). In particular dot-forward, fastforward and /var/mail delivery are pretty major improvements if you're very attached to sendmail. Evan
Re: Why Red Hat is not distributing qmail
Sam Said: No, the question is very specific: if Red Hat botched the sendmail RPM, how does that sole event somehow translate into Eric Allman's reputation being affected in any way? The answer, of course, is that it doesn't. This line of argument is silly. No it's not. If i'm evaluating a system and program A really sucks, or is a burden to administer, the common response would be "Man, that program sucks" and I would remember that experience for a time. The Author of the program may not be personally affected, but the relationship of "sendmail"-Allman or "qmail"-DJB has been made and I would be much more cautious of the next Allman or DJB package that was available. I think that saying a personal reputation would be injured is a bit far, but a professional one would be. Paul D. Farber II Farber Technology 717-628-5303 [EMAIL PROTECTED]
Re: Why Red Hat is not distributing qmail
[EMAIL PROTECTED] Mate
Re: Why Red Hat is not distributing qmail
On Wed, 30 Dec 1998, Sam wrote: On Wed, 30 Dec 1998, Dave Sill wrote: Brister has to deal with whatever gunk is in the RPM because he's going to get questions about it. If that's true, Brister would've never had the time to write inn 2.0, While I agree with Sam here (frankly, people will complain about problems to their vendor, not to the author, whom they might not even know about), I have to speak up on this point. James Brister was responsible for the packaged release of INN 2.0, but the majority of the coding was done by others. The ISC only oversees releases now; the majority of the INN developers now aren't even remotely associated with the ISC. As time goes by, you may see some other vendors make some inquiries as well. However, the end result will always be the same. Exactly. Actually, the licensing might be acceptable to a commercial OS vendor who doesn't want people on-staff who deal with software patches directly. But any vendor who wants to be responsive to their customers will either have to choose: a) develop their own MTA, or contract with someone who does it for them and gives them responsiveness guarantees through the contract b) go with an Open Source(tm) MTA, which gives them the ability to ensure that they can respond to security problems with their own distributions without being locked into the schedule of an external developer. Just like everyone here assumes the worst of Red Hat (that they will introduce problems to QMail), Red Hat must assume the worst of DJB (in that he might not be available when a security issue arises, and hence, even with the availability of third-party (or their own) patches, their hands are tied). But, I've said many times: it's DJB's software, and his to choose how to license. I migrated a long time ago to QMail, and while it's technically an excellent product, the licensing disagrees with me. Hence, I've switched to another product (postfix) to replace it, because the license sits better with me (with a built-in understanding that the author won't be around to maintain it forever), and still (in my mind) achieves the level of technical excellence that QMail reaches. It's not as mature as QMail, but in my mind it has more hope of gaining widespread acceptance than QMail. And with open source projects, more eyes are always a good thing. (For anyone who thinks my decision was because of the author: nope, personality issues never even came into it. With the bickering I've seen between DJB and Weitse, I wouldn't run EITHER product if personality meant anything to me. ;-) -- Edward S. Marshall [EMAIL PROTECTED] [ What goes up, must come down. ] http://www.logic.net/~emarshal/ [ Ask any system administrator. ] Linux labyrinth 2.2.0-pre1 #1 Tue Dec 29 16:35:16 CST 1998 i586 unknown 8:25pm up 1 day, 2:17, 4 users, load average: 0.00, 0.00, 0.00
Re: Why Red Hat is not distributing qmail
Russell Nelson [EMAIL PROTECTED] wrote: The basic problem is that [Dan doesn't] trust Redhat. Good for him! He'd be a fool to trust them. There's no basis for trust between them. If [he] trusted them, then [he] would give them the freedom to distribute modified binaries. If pigs had wings... Redhat is returning that distrust. Good for them! (See above.) Not only that, but Donnie is so confident that [Dan has] sufficiently marginalized [him]self that he isn't going to bother to dispute [him]. I don't think thats it, really. I think Donnie/Red Hat are simply not sufficiently motivated to include qmail in RHL. I suspect their reasoning goes something like this: Sendmail is *the* UNIX mailer. Everyone knows how to work it. It's well documented, well proven, and hopefully most of the major bugs have been found. We can tweak the source any way we see fit. Not many (paying) customers are complaining about it. Sure, qmail is better, but when we compare the benefits to the costs, it doesn't make economic sense to switch. -Dave
Re: Why Red Hat is not distributing qmail
Bill Parker [EMAIL PROTECTED] Dave Sill wrote: Sendmail is *the* UNIX mailer. Everyone knows how to work it. It's well documented, well proven, and hopefully most of the major bugs have been found. We can tweak the source any way we see fit. Not many (paying) customers are complaining about it. Sure, qmail is better, but when we compare the benefits to the costs, it doesn't make economic sense to switch. Ahem! if you are installing a system from scratch (as i did about 5 months ago) and you read horror stories about what a pain it is to admin sendmail, it makes perfectly good sense to install what you want when you are loading the operating system..:) In my case, i installed Qmail v1.03 and never have looked back (except for a few small problems, etc).. Of course I agree completely. I was merely guessing at Red Hat's reasons for not switching to qmail. Remember, Red Hat is a big bux commercial operation (see recent news reports of substantial investment in Red Hat by Intel). They don't produce Open Source Software because they're nice guys and it makes them feel good to give away their wonderful operating system. They're in the business to make money. They do it by selling shrink wrapped RHL, support services, and various LINUX add-ons. To a certain extent, the quality of the components of RHL can affect their bottom line: quality is something that some customers are willing to pay for. But, as Microsoft, Netscape, and Red Hat's own experience has amply demonstrated, the public is all too eager to accept buggy, unreliable software. Clearly, quality isn't the only criterion--or even all that important a criterion--to the average customer. If Red Hat was a bunch of geeks dedicated to furthering the hacker ethic, replacing sendmail with qmail or even postfix or exim would be a no-brainer. They'd evaluate the choices, pick a winner, and do whatever it would take to implement the switch. But Red Hat is more like a bunch of executives dedicated to growing the business and raising profits. Their techies might argue for replacing sendmail on the grounds that it would improve the quality of their product and hopefully avoid some negative publicity the next time sendmail is hacked, but that's not enough to justify the switch. The executives will want to be sure that the costs of switching are lower than the benefits of switching--otherwise they'll lose some of their precious growth or profits. So what are the costs to Red Hat of switching from sendmail to another MTA? Here are a few: o they have to select an alternative o they have to test the alternative on a variety of platforms in a variety of situations o they have to incorporate the alternative into the next release o they have to change various documentation o they have to support their sendmail customers in the migration There are also risks: o what if users don't want to switch? o what if the replacement has problems? I'm sure there are others, but you get the idea. From Red Hat's point of view, the inertia behind sendmail is substantial and the mere availability of a superior alternative isn't compelling enough to make them switch. -Dave
Re: Why Red Hat is not distributing qmail
On Tue, Dec 29, 1998 at 04:12:27PM -0500, Dave Sill wrote:
Remember, Red Hat is a big bux commercial operation (see recent news
reports of substantial investment in Red Hat by Intel). They don't
produce Open Source Software because they're nice guys and it makes
them feel good to give away their wonderful operating system.
Only part right. Those I've talked to at redhat say that they give
their work back to the community, and for free, because they believe
it's a valid business model, but also because it makes them feel good.
They were and are bucking the pointy-haired trend in the computer
world. A big part of it is because what they're doing makes them feel
good.
They're
in the business to make money. They do it by selling shrink wrapped
RHL, support services, and various LINUX add-ons.
That too. But they do more of the "because it makes us feel good"
kind of thing then anyone else I know in the community (OSS, Free
Software, what have you. Even RMS likes them). That's partly becaue
their business gives them the revenue that lets them support the stuff
that lets them feel good. It's not exactly cut-n-dried.
If Red Hat was a bunch of geeks dedicated to furthering the hacker
ethic, replacing sendmail with qmail or even postfix or exim would be
a no-brainer. They'd evaluate the choices, pick a winner, and do
whatever it would take to implement the switch.
I disagree. The choices are more then technical, because Dan makes it
so. View debian linux, or stampede linux - they are what you
describe, as I believe the freebsd and openbsd core teams are. To my
knowledge none of these essentially hacker systems, or redhat's
hack-branch ("rawhide") have any option for qmail to be installed by
default. Obviously something besides technical considerations come
into play. Maybe something about qmail conflicts with the ethic of a
sizeable percentage of hackers?
But Red Hat is more like a bunch of executives dedicated to growing
the business and raising profits. Their techies might argue for
replacing sendmail on the grounds that it would improve the quality of
their product and hopefully avoid some negative publicity the next
time sendmail is hacked, but that's not enough to justify the
switch.
AFAIK this was a group decision. Ask them yourself next time you see
them at a trade show. They made up their mind at least 2 years ago,
and it seemed to be a unanimous decision throughout the group of about
10 geeks that ran the technical side at the time. Never mind that
redhat uses qmail for all of their list systems...
The executives will want to be sure that the costs of
switching are lower than the benefits of switching--otherwise they'll
lose some of their precious growth or profits.
I disagree again. If it was viable for them to offer qmail as a
replacement beyond the technical considerations (and Dan has gone to
alot of trouble so that there aren't any technical considerations in
the simplest cases) then they would. So what else is there?
[deletia]
I'm soundly opposed to the picture you paint of linux or other free
OS' being monolithic inflexible distributions. Options can be
offered, and are at install time. Because your opinions seem to rest
on that assumption I won't address your points, which are mostly valid
but aren't stated in a way that allows them to mate with the situation
as I understand it. If your POV (as I read it) that the motivating
reason redhat doesn't do this is because they're a pointy-haired
business was at all accurate then all non-pointy-haired OS
distributions should have qmail, right? Well, where is qmail? I see
wu-ftpd being replaced by proftpd in places, I see apache installed
instead of CERN or NCSA httpd, I see gnu utilities instead of BSD
utils, or where appropriate BSD utils instead of GNU utils, I see
network code getting tightened up, kernels being scrutinized, but I
don't see qmail anywhere.
What's the answer?
I'm sure there are others, but you get the idea. From Red Hat's point
of view, the inertia behind sendmail is substantial and the mere
availability of a superior alternative isn't compelling enough to make
them switch.
Then why haven't any of the other many free operating system
distributions moved towards qmail?
-Peter
Re: Why Red Hat is not distributing qmail
On Tue, Dec 29, 1998 at 04:25:55PM -0500, Sam wrote: Not when they have a functional MTA available, that doesn't come with any strings attached, that quietly installs itself, non-relaying out of the box, and will even do certain things that Qmail cannot do, such as reject non-resolvable envelope sender addresses, reject delivery attempts to non-existent local users, and support RBL lookups with a single configuration switch. There's absolutely no reason for Red Hat to switch to Qmail, so let's just stop beating a dead horse. qmail doesn't reject delivery attempts to nonexistant local users?? I guess this is true if you have a .qmail-default in ~alias, but otherwise the message will bounce, no? --Adam
Re: Why Red Hat is not distributing qmail
On 29-Dec-98 22:30:41, Adam D. McKenna wrote something about "Re: Why Red Hat is not distributing qmail". I just couldn't help replying to it, thus: On Tue, Dec 29, 1998 at 04:25:55PM -0500, Sam wrote: [sendmail] box, and will even do certain things that Qmail cannot do, such as reject non-resolvable envelope sender addresses, reject delivery attempts to non-existent local users, and support RBL lookups with a single qmail doesn't reject delivery attempts to nonexistant local users?? No, in fact it doesn't. I guess this is true if you have a .qmail-default in ~alias, Doesn't make a difference. but otherwise the message will bounce, no? Yes, the message will bounce if it cannot be delivered. Regards, /¯¯T¯\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | Which is worse: Ignorance or apathy? Who knows... Who cares...|
Re: Why Red Hat is not distributing qmail
Sam wrote: On 23 Dec 1998, D. J. Bernstein wrote: In fact, forks are traditional UNIX vendor behavior. I described how Debian had screwed up cross-platform compatibility by changing the qmail file locations. He dismissed my concerns, and said that he needed to change the paths too. I don't recall many questions on the list from Debian users and how confused they are with the different location of all the files. As far as vendor's traditional packaging, they are not forks, but site-specific customizations. If they were real forks, the vendor would have its own source tree that they work on independently. Both Debian and Redhat do not maintain any separate code trees. The source code they shipped with their OS is the original package source code. And any OS-specific patches are provided separately. Although they turn the sources into something funny -- SRPMS as far as I know. Don't know the exact detail of this. I do know I like to have my packages in /usr/local/pkgname, like Samba, Squid, Postgres, Apache etc... do. I don't like the RH way of putting everything into /usr. Speaking about that, forgive the naîve question Dan, but what's so special about /var? Cheers, Juan
Re: Why Red Hat is not distributing qmail
Once upon a time, Donnie Barnes Is he the only one making decisions at RH. What kind of freedom did RH have when they *started* distributing Netscape? Mate
Re: Why Red Hat is not distributing qmail
Is he the only one making decisions at RH. What kind of freedom did RH have when they *started* distributing Netscape? RedHat has AFAIK changed policy since then. (They used to include other commercial programs in their distribution, but stopped doing so) bt
Re: Why Red Hat is not distributing qmail
On 23 Dec 1998 06:40:20 -, D. J. Bernstein wrote: I tried to work with Donnie Barnes. I put a lot of effort into making qmail distributable in binary form. But he isn't willing to guarantee cross-platform compatibility. It saddens me that he hasn't been honestly telling his users the nature of our disagreement. RedHat has SECURITY announcements. Often, the problem is that the package is screwed up, not that the source program itself is. Directories have the worng permission, etc. They fix it and the announcement clearly states that it was the _package_ not the _program_. This would not give qmail a bad name. RedHat may well screw it up, but that's [mainly] their problem. RedHat already distribute "non-free" packages, i.e. packages with restrictions above GPL. They do not need to make qmail _the_ redhat MTA, just make it avaialble as an option. What we need is one good and secure rpm. I want maildir, not some stupid mbox spool. RedHat are likely to do the latter for ease of sendmail compatibility. So, I'll keep building qmail on my [redhat linux] system. However, I'd rather the rest of the word used a partially screwed up qmail than sendmail. So, DJB and DB are both 100% correct. A compromise, is worth more than the sum of the merits of both points of view. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
RE: Why Red Hat is not distributing qmail
Well.. One other "related" thing that would need to be updated if you want Maildir mail handling is the modification of the "skeleton" directory/User Add/Del Scripts. If you used qmail w/Maildir, the rpm would need to modify the User Add scipts and skeleton Directory to set up new users properly. It could also be made smart enough to get rid of the /var/mail directory. Same for User Del, it would have to know to not bother with /var/mail Matt Soffen Webmaster - http://www.iso-ne.com/ == Boss- "My boss says we need some eunuch programmers." Dilbert - "I think he means UNIX and I already know UNIX." Boss- "Well, if the company nurse comes by, tell her I said never mind." - Dilbert - == -- From: Fred Lindberg[SMTP:[EMAIL PROTECTED]] Reply To: Fred Lindberg Sent: Wednesday, December 23, 1998 11:30 AM To: [EMAIL PROTECTED] Subject: Re: Why Red Hat is not distributing qmail On 23 Dec 1998 06:40:20 -, D. J. Bernstein wrote: I tried to work with Donnie Barnes. I put a lot of effort into making qmail distributable in binary form. But he isn't willing to guarantee cross-platform compatibility. It saddens me that he hasn't been honestly telling his users the nature of our disagreement. RedHat has SECURITY announcements. Often, the problem is that the package is screwed up, not that the source program itself is. Directories have the worng permission, etc. They fix it and the announcement clearly states that it was the _package_ not the _program_. This would not give qmail a bad name. RedHat may well screw it up, but that's [mainly] their problem. RedHat already distribute "non-free" packages, i.e. packages with restrictions above GPL. They do not need to make qmail _the_ redhat MTA, just make it avaialble as an option. What we need is one good and secure rpm. I want maildir, not some stupid mbox spool. RedHat are likely to do the latter for ease of sendmail compatibility. So, I'll keep building qmail on my [redhat linux] system. However, I'd rather the rest of the word used a partially screwed up qmail than sendmail. So, DJB and DB are both 100% correct. A compromise, is worth more than the sum of the merits of both points of view. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: Why Red Hat is not distributing qmail
Sam writes: I don't recall many questions on the list from Debian users and how confused they are with the different location of all the files. Debian didn't distribute the binary package. They knew they were violating the var-qmail compatibility requirements. As far as vendor's traditional packaging, they are not forks, but site-specific customizations. Whatever you call it, the result is a huge hassle for the users. ---Dan
