Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Fri, Jan 26, 2001 at 09:16:54AM -0800, [EMAIL PROTECTED] wrote: On Thu, 25 Jan 2001, Markus Stumpf wrote: If AOL or hotmail would decide to change their MX records to your mailserver this will for sure also cause you problems. Actually, Qmail works fine as an incoming MX for Hotmail.com. mail.hotmail.com, one of Hotmail's incoming mx machines, runs Qmail. [1] [snip] [1] Qmail's fingerprint is that it accepts the MAIL FROM: [EMAIL PROTECTED] in the SMTP session being shortened to MAIL [EMAIL PROTECTED] The mail.hotmail.com that I just telnetted to on port 25 did not except this shortened version. It was also completely unsimilar to qmail-smtpd. Greetz, Peter.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Thu, Jan 25, 2001 at 10:18:11PM -, D. J. Bernstein wrote: Patrick Bihan-Faou writes: If you don't count that as a bug in qmail, then I don't know what is a bug... In fact, it's not a bug; it's a portability problem. If you were using OpenBSD, you'd see outgoing connections to 0.0.0.0 rejected with EINVAL. Even BSD/OS, under which qmail including 1.03 was developed, 0.0.0.0 is the localhost. It is so on every other OS. You are describing something that OpenBSD does different from the rest of the world. Greetz, Peter.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Markus Stumpf [EMAIL PROTECTED] writes: On Thu, Jan 25, 2001 at 06:32:47PM -0500, Scott Gifford wrote: Markus Stumpf [EMAIL PROTECTED] writes: If AOL or hotmail would decide to change their MX records to your mailserver this will for sure also cause you problems. No it won't. qmail will give an error that the MX records points back to itself, and bounce the message. I don't think that any mailserver out there will be able to handle the load if AOL or Hotmail will change the MX record to point at that system (without prior notice). This would be a DOS just like the 0.0.0.0 is. Oh, I see. Yes, that's correct. There are all kinds of DOS attacks against any public Internet service. The ones to worry about are the ones that let a single user with a slow Internet connection deny service to a large number of people. The ones that require being singled out for destruction by large ISPs, there's nothing that can really be done about. -ScottG.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
"D. J. Bernstein" [EMAIL PROTECTED] writes: Patrick Bihan-Faou writes: If you don't count that as a bug in qmail, then I don't know what is a bug... In fact, it's not a bug; it's a portability problem. If you were using OpenBSD, you'd see outgoing connections to 0.0.0.0 rejected with EINVAL. Although the proposed fix, adding 0.0.0.0 to ipme, doesn't pose any kind of compatibility problem. -ScottG.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html If you don't count that as a bug in qmail, then I don't know what is a bug... Patrick. "Scott Gifford" [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Matt Brown [EMAIL PROTECTED] writes: This has been a feature of recent spam, which is probably why it's now an issue. Several spam senders are now having sender addresses of spammer@spamdomain, where spamdomain resolves via DNS to '0.0.0.0'. Eventually qmail rejects the message because it recognises that it's looped around too much, of course. Right, but it's a very effective (perhaps inadvertant) DOS tool. If you can generate a stream of 10 messages/sec of these, it's the equivalent of generating about 300 messages/sec --- a great way of turning a puny dial-up connection into a mail server crushing machine. We had a spammer sending a huge number of messages to users at this address (sigh their fake bounce addresses are now getting on each others' list...), which was causing our not-processed queues to hover around 100, which was causing regular messages to be processed very slowly. Since qmail works around this simple mail loop for other address referring to the local machine, it should do so for 0.0.0.0 as well. --ScottG.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Thu, Jan 25, 2001 at 12:40:47PM -0500, Patrick Bihan-Faou wrote: Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html If you don't count that as a bug in qmail, then I don't know what is a bug... You quote it, but have you also read the document? Especially the "Rules" section, part 1. (and also 8.1) \Maex -- SpaceNet AG| Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research Development | D-80807 Muenchen| Fax: +49 (89) 32356-299 Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html I don't think so. The challenge says: "Bugs that qualify for the prize, subject to the other conditions outlined in these rules, must be one of the following: - Remote exploits that give login access. - Local or remote exploits that grant root privileges. - Local or remote exploits that grant read or write access to a file the user can't normally access because of UNIX access controls (owner/group/mode). - Local or remote exploits that cause any of the long-lived qmail processes (currently: qmail-send, qmail-rspawn, qmail-lspawn, or qmail-clean) to terminate." This attack merely causes messages to loop a bit before bouncing. This barely even qualifies as a DOS attack. Note also that at http://cr.yp.to/qmail/guarantee.html: "I also specifically disallowed denial-of-service attacks: they are present in every MTA, widely documented, and very hard to fix without a massive overhaul of several major protocols" -- gowen -- Greg Owen -- [EMAIL PROTECTED] SoftLock.com is now DigitalGoods!
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
"Patrick Bihan-Faou" [EMAIL PROTECTED] wrote: Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html If you don't count that as a bug in qmail, then I don't know what is a bug... Sure, it's a bug. Dan didn't anticipate that spammers would set up MX's pointing to 0.0.0.0. But it's not a security bug, and it wouldn't have won the Security Challenge if it was still in effect. -Dave
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
?? definitely not eligible. where's the exploit? Patrick Bihan-Faou writes: Well I guess that this one is definitely elligible for the "qmail security challenge". If you don't count that as a bug in qmail, then I don't know what is a bug... Patrick. "Scott Gifford" [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Matt Brown [EMAIL PROTECTED] writes: This has been a feature of recent spam, which is probably why it's now an issue. Several spam senders are now having sender addresses of spammer@spamdomain, where spamdomain resolves via DNS to '0.0.0.0'. Eventually qmail rejects the message because it recognises that it's looped around too much, of course. Right, but it's a very effective (perhaps inadvertant) DOS tool. If you can generate a stream of 10 messages/sec of these, it's the equivalent of generating about 300 messages/sec --- a great way of turning a puny dial-up connection into a mail server crushing machine. We had a spammer sending a huge number of messages to users at this address (sigh their fake bounce addresses are now getting on each others' list...), which was causing our not-processed queues to hover around 100, which was causing regular messages to be processed very slowly. Since qmail works around this simple mail loop for other address referring to the local machine, it should do so for 0.0.0.0 as well. --ScottG. - Paul Theodoropoulos [EMAIL PROTECTED] Senior Unix Systems Administrator Syntactically Subversive Services, Inc. http://www.anastrophe.net Downtime Is Not An Option
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Thu, Jan 25, 2001 at 12:40:47PM -0500, Patrick Bihan-Faou wrote: Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html If you don't count that as a bug in qmail, then I don't know what is a bug... It's a bug. However, it would not qualify: 8. The following types of bugs are specifically disqualified: + Exploits that involve corrupting DNS data, breaking TCP/IP, breaking NFS, or denying service (except for the case above). Also, http://cr.yp.to/qmail/guarantee.html specifically mentions that DoS is not part of the deal. Greetz, Peter.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Thu, Jan 25, 2001 at 12:40:47PM -0500, Patrick Bihan-Faou wrote: Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html If you don't count that as a bug in qmail, then I don't know what is a bug... You quote it, but have you also read the document? Especially the "Rules" section, part 1. (and also 8.1) Well failure to recognize that 0.0.0.0 is yourself is not quite DNS related exploit. It is a bug. sarcasm I like these rules that say "yeah we are setting up a challenge, but there is no way that you could ever win it"... If you ask me, qmail is far from bug free... The first security issue with this product is itself: the code is completely obfuscated (I know I know, style is a matter of taste), there is 0 line of comments in the code (hey isn't the fact that qmail code is "small" one of its selling points ? remove comments and you reduced the code size...) Read Bruce Schneier's comment on these type of contests in his latest book... /sarcasm This 0.0.0.0 problem can easily be deflected by saying "some stupid people mis-configure DNS to cause you problem (clause 8)", but the facts are: - other MTA handle this properly (not qmail) - this sort of "attack" is in use and causing problems with site that selected qmail as their MTA So saying "it does not fit our challenge because you need to use DNS to perform the attack" is like saying "well qmail is perfectly safe if you don't use it in the real world"... Good PR move guys, and a cheap one too! Well my answer to this is "don't use qmail" Patrick.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Oh and for the fact that the challenge is closed. I mean cool more money to FSF. But still my comment is more on "what constitute a problem with qmail". I don't really care for the challenge itself, but more on the attitude of saying "this is not a qmail issue, but something else's fault". Patrick.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Thu, Jan 25, 2001 at 01:56:45PM -0500, Patrick Bihan-Faou wrote: Well failure to recognize that 0.0.0.0 is yourself is not quite DNS related exploit. It is a bug. If AOL or hotmail would decide to change their MX records to your mailserver this will for sure also cause you problems. But neither is a *security* bug. the code is completely obfuscated (I know I know, style is a matter of taste), there is 0 line of comments in the code The ability to read the code depends on your C language skills. The ability to work with the code depends on the tools you have and use (ever given ctags a try?). Limited capabilities don't mean the code is obfuscated. A book written in Kishuaheli will look obfuscated to most people on this planet and it doesn't have comments, too. However this is not a criteria for the quality of the book. Well my answer to this is "don't use qmail" Nobody says you have to. \Maex -- SpaceNet AG| Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research Development | D-80807 Muenchen| Fax: +49 (89) 32356-299 Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
begone, troll. Patrick Bihan-Faou writes: On Thu, Jan 25, 2001 at 12:40:47PM -0500, Patrick Bihan-Faou wrote: Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html If you don't count that as a bug in qmail, then I don't know what is a bug... You quote it, but have you also read the document? Especially the "Rules" section, part 1. (and also 8.1) Well failure to recognize that 0.0.0.0 is yourself is not quite DNS related exploit. It is a bug. sarcasm I like these rules that say "yeah we are setting up a challenge, but there is no way that you could ever win it"... If you ask me, qmail is far from bug free... The first security issue with this product is itself: the code is completely obfuscated (I know I know, style is a matter of taste), there is 0 line of comments in the code (hey isn't the fact that qmail code is "small" one of its selling points ? remove comments and you reduced the code size...) Read Bruce Schneier's comment on these type of contests in his latest book... /sarcasm This 0.0.0.0 problem can easily be deflected by saying "some stupid people mis-configure DNS to cause you problem (clause 8)", but the facts are: - other MTA handle this properly (not qmail) - this sort of "attack" is in use and causing problems with site that selected qmail as their MTA So saying "it does not fit our challenge because you need to use DNS to perform the attack" is like saying "well qmail is perfectly safe if you don't use it in the real world"... Good PR move guys, and a cheap one too! Well my answer to this is "don't use qmail" Patrick. - Paul Theodoropoulos [EMAIL PROTECTED] Senior Unix Systems Administrator Syntactically Subversive Services, Inc. http://www.anastrophe.net Downtime Is Not An Option
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Thu, Jan 25, 2001 at 01:56:45PM -0500, Patrick Bihan-Faou wrote: So saying "it does not fit our challenge because you need to use DNS to perform the attack" is like saying "well qmail is perfectly safe if you don't use it in the real world"... Good PR move guys, and a cheap one too! Well my answer to this is "don't use qmail" Patrick. If you're that bitter about people accurately explaining to you that a bug is not necessarily the same as a security exploit, then it's probably best if you take your own advice. You're not forced to use qmail. You're not forced to particiate here and listen to answers you don't want to hear. If qmail doesn't suit you, or the qmail community doesn't suit you then it's in your and our best interest to pick an MTA that suits your ideals. You'll feel better and we won't notice your absence. Regards.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Well failure to recognize that 0.0.0.0 is yourself is not quite DNS related exploit. It is a bug. I'll buy that, but it isn't a security hole. You did note the word "security" between "qmail" and "challenge," yes? Its in the titlebar, the large words at the top of the page, and the first paragraph. I like these rules that say "yeah we are setting up a challenge, but there is no way that you could ever win it"... It wasn't a bug hunt, it was a security challenge. The rules listed are reasonable, if you keep that in mind. If you ask me, qmail is far from bug free... Okay, but how many of those bugs can be exploited to breach security? (NOTE: a DOS is not a security breach.) Please, go find one, there is still a $500 prize available. - this sort of "attack" is in use and causing problems with site that selected qmail as their MTA This sort of "attack" causes little more trouble than double-bounces. Frankly, we've discussed DOS scenarios with qmail that make this look like a piece of wet popcorn. Note that qmail's integral mail loop detection stops this attack quickly. So saying "it does not fit our challenge because you need to use DNS to perform the attack" is like saying "well qmail is perfectly safe if you don't use it in the real world"... Good PR move guys, and a cheap one too! Nobody said that. We said it wasn't a security breach, it was a DOS, and an extremely limited DOS at that. If you don't understand the difference, go read some more. Let's read that line again: "bugs are specifically disqualified: Exploits that involve corrupting DNS data, breaking TCP/IP, breaking NFS, or denying service (except for the case above). " You apparently stopped at the first comma. Try going all the way to the period. Well my answer to this is "don't use qmail" Given your logic, you should stop using computers. I've noticed bugs at all levels, from the BIOS and CPU on up. But then you wouldn't get to go trolling, now would you? -- gowen -- Greg Owen -- [EMAIL PROTECTED] SoftLock.com is now DigitalGoods!
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Patrick Bihan-Faou [EMAIL PROTECTED] wrote: Well failure to recognize that 0.0.0.0 is yourself is not quite DNS related exploit. It is a bug. sarcasm I like these rules that say "yeah we are setting up a challenge, but there is no way that you could ever win it"... The only reason it couldn't be won was that there were no security bugs in qmail. The exact same conditions, attached to sendmail of the time, would have resulted in many, many winners. If you ask me, qmail is far from bug free... The first security issue with this product is itself: the code is completely obfuscated (I know I know, style is a matter of taste), there is 0 line of comments in the code (hey isn't the fact that qmail code is "small" one of its selling points ? remove comments and you reduced the code size...) Don't like it? Don't use it. There's plenty of other MTAs out there. If you want djb to eat crow _and_ give you money, he's offering a USD$500 guarantee on the security of djbdns. Go wild; find a security bug. I fully expect that money to remain unclaimed. 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: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Patrick Bihan-Faou writes: If you don't count that as a bug in qmail, then I don't know what is a bug... In fact, it's not a bug; it's a portability problem. If you were using OpenBSD, you'd see outgoing connections to 0.0.0.0 rejected with EINVAL. ---Dan
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Among other thins, Patrick Bihan-Faou said: Read Bruce Schneier's comment on these type of contests in his latest book... Name of book, please. Well my answer to this is "don't use qmail" So, what do you recommend? Patrick.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Read Bruce Schneier's comment on these type of contests in his latest book... Name of book, please. "Secrets and Lies" if my memory serves me right. Well my answer to this is "don't use qmail" So, what do you recommend? I am not recommending anything, choose a solution based on your needs. I looked at many MTA. Qmail is really nice for a large number of things and is usually reliable. But as I started to want things that do not fit with its design assumptions it became really difficult to play with it. As far as overall code quality and design quality goes, postfix is the best MTA I have seen so far (IMO). But as with a lot of things this is a matter of personal preferences and even religion for some. I currently use both qmail and postfix. Any new system I build uses postfix. I don't want to start a holy war on these issues as they are not worth the effort. My main motivations to move to postfix were: - qmail obscure licensing terms (for my needs) - postfix is generally more flexible and easier to configure for fancy things - postfix performance is on par with qmail - and a few other reasons that are not worth mentioning Why I used qmail in the past: - easier to configure than sendmail - more reliable than sendmail - only true alternative to sendmail (at the time) - good performance - easy to use for "simple" cases (where "simple" does not mean simplistic/useless, but means "typical") Patrick.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Markus Stumpf [EMAIL PROTECTED] writes: On Thu, Jan 25, 2001 at 01:56:45PM -0500, Patrick Bihan-Faou wrote: Well failure to recognize that 0.0.0.0 is yourself is not quite DNS related exploit. It is a bug. If AOL or hotmail would decide to change their MX records to your mailserver this will for sure also cause you problems. No it won't. qmail will give an error that the MX records points back to itself, and bounce the message. qmail knows that MX records that point back to you are a problem, it just doesn't know that 0.0.0.0 points back to itself. That's why it's a bug. --ScottG.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Hi Mark, Patrick. If you're that bitter about people accurately explaining to you that a bug is not necessarily the same as a security exploit, [...] Well I guess I disagree on the meaning of a security problem. If you can use this trick to create a DOS attack on a system, to me that would qualify as a security problem. Of course this trick will not provide the attacker with root access to the machine, so in a stricter sense it is not a security exploit, but I find that definition a bit too narrow. I am not bitter about it, I am just a bit hot tempered at times :). off topic However I find it a bit extreme to be called an idiot because I state some of my views. I certainly did not intend to call people names, and I don't think I did. I find it a bit disturbing that people are always ready to call you names as soon as you state even the slightest negative comment about qmail. I guess I will never understand that kind of passion (zealotery ?), but it is always amusing to witness. /off topic Patrick.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Thu, Jan 25, 2001 at 06:32:47PM -0500, Scott Gifford wrote: Markus Stumpf [EMAIL PROTECTED] writes: If AOL or hotmail would decide to change their MX records to your mailserver this will for sure also cause you problems. No it won't. qmail will give an error that the MX records points back to itself, and bounce the message. I don't think that any mailserver out there will be able to handle the load if AOL or Hotmail will change the MX record to point at that system (without prior notice). This would be a DOS just like the 0.0.0.0 is. qmail knows that MX records that point back to you are a problem, it just doesn't know that 0.0.0.0 points back to itself. That's why it's a bug. I never said it's not a bug, it's IMHO just not a security bug. It's triggered by a DNS misconfiguration (done on purpose). And, btw., thanks for finding it and supplying a fix. \Maex -- SpaceNet AG| Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research Development | D-80807 Muenchen| Fax: +49 (89) 32356-299 Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Pavel Kankovsky [EMAIL PROTECTED] wrote: Now, how old qmail 1.03 is? CHANGES in qmail-1.03.tar.gz say it was released on June 15 1998. Hmm...this predates the change in question (January 11 1999), doesn't it? http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/tcp_usrreq.c Revision 1.20; dated Feb 28 1998. Please, stop now. -- Dan Peterson [EMAIL PROTECTED] http://danp.net
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Scott Gifford [EMAIL PROTECTED] writes: Keary Suska [EMAIL PROTECTED] writes: This would definitely be a bug of concern--even sendmail (yoiks!) knows how to handle 0.0.0.0. But shouldn't qmail bounce the message as a possible MX loop? It should, but does not. Putting it into ipme would cause it to. This has been a feature of recent spam, which is probably why it's now an issue. Several spam senders are now having sender addresses of spammer@spamdomain, where spamdomain resolves via DNS to '0.0.0.0'. Eventually qmail rejects the message because it recognises that it's looped around too much, of course. -Matt -- | Matthew J. Brown - Senior Network Administrator - NBCi Shopping | | 1983 W. 190th St, Suite 100, Torrance CA 90504 | | Phone: (310) 538-7122| Work: [EMAIL PROTECTED] | | Cell: (714) 457-1854| Personal: [EMAIL PROTECTED] |
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Matt Brown [EMAIL PROTECTED] wrote: This has been a feature of recent spam, which is probably why it's now an issue. Several spam senders are now having sender addresses of spammer@spamdomain, where spamdomain resolves via DNS to '0.0.0.0'. Eventually qmail rejects the message because it recognises that it's looped around too much, of course. Here's a possible fix. In control/virtualdomains: [0.0.0.0]:alias-devnull And in ~alias/.qmail-devnull-default # Which should throw away all mail to MX's resolving to 0.0.0.0. -Dave
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Matt Brown [EMAIL PROTECTED] writes: This has been a feature of recent spam, which is probably why it's now an issue. Several spam senders are now having sender addresses of spammer@spamdomain, where spamdomain resolves via DNS to '0.0.0.0'. Eventually qmail rejects the message because it recognises that it's looped around too much, of course. Right, but it's a very effective (perhaps inadvertant) DOS tool. If you can generate a stream of 10 messages/sec of these, it's the equivalent of generating about 300 messages/sec --- a great way of turning a puny dial-up connection into a mail server crushing machine. We had a spammer sending a huge number of messages to users at this address (sigh their fake bounce addresses are now getting on each others' list...), which was causing our not-processed queues to hover around 100, which was causing regular messages to be processed very slowly. Since qmail works around this simple mail loop for other address referring to the local machine, it should do so for 0.0.0.0 as well. --ScottG.
