The qmail-0.0.0.0 patch was written by Scott Gifford . Here are some excerpts from the original discussion that led to writing this patch: To: qmail@lists.cr.yp.to Subject: Handling an MX record of 0.0.0.0 or 127.0.0.1 From: Scott Gifford Date: Tue, 16 Jan 2001 13:17:15 -0500 We received an influx of mail today addressed to (probably bogus) users at the domain 'groupprojects.net'. This domain has the following MX record: groupprojects.net preference = 0, mail exchanger = 0.0.0.0 When we received the message, qmail connected to 0.0.0.0 to deliver the mail. 0.0.0.0 connects to 127.0.0.1, so qmail ended up connected to itself. It continued to deliver the message to itself, and because 127. is allowed to relay on my system, the message was accepted. Then qmail would immediately begin delivering the message to itself again. Wash, rinse, repeat. I stopped this from happening by denying connections from 127. in my TCP rules file for qmail-smtpd (I changed 127.:allow,RELAYCLIENT="",,RBLSMTPD=""DENYMAIL="DNSCHECK" to 127.:deny ), but this seemed like kind of a kludgey solution. So I have 2 questions. 1) Is there a better way to do this? Allowing 127. to relay is a convenient way for me to test. I'd like to be able to null-route to these addresses in smtproutes instead, but I don't see a way to do that. 2) Will anything bad happen as a result of blocking SMTP connections from 127.? I can't think of what this would break, but I've always had this address allowed to relay before . . . Thanks, ------ScottG. To: qmail@lists.cr.yp.to Subject: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or127.0.0.1) From: Scott Gifford Date: Mon, 22 Jan 2001 17:20:49 -0500 Scott Gifford writes: > We received an influx of mail today addressed to (probably bogus) > users at the domain 'groupprojects.net'. This domain has the > following MX record: > > groupprojects.net preference = 0, mail exchanger = 0.0.0.0 > > When we received the message, qmail connected to 0.0.0.0 to deliver > the mail. 0.0.0.0 connects to 127.0.0.1, so qmail ended up connected > to itself. It continued to deliver the message to itself, and because > 127. is allowed to relay on my system, the message was accepted. Then > qmail would immediately begin delivering the message to itself again. > Wash, rinse, repeat. [ ... ] Further investigation of this problem has led me to what seems to be a subtle bug in qmail. in ipme.c, qmail tries to decide what IP addresses will connect back to itself. It does this by finding the IP addresses of all network interfaces on the system, and putting them into an ipalloc structure called ipme. Then, in qmail-remote.c, it deals with the situation where the best-preference MX for a domain is itself, but this domain doesn't appear in control/locals, by issuing a permanent failure for the message, via perm_ambigmx(), which displays the familiar error message: Sorry. Although I'm listed as a best-preference MX or A for that host, it isn't in my control/locals file, so I don't treat it as local. (#5.4.6) This is necessary to prevent a tight internal mail loop, like the one I encountered below. Otherwise, qmail will see that the message isn't local, qmail-remote will connect to its own IP address, and the message will be re-injected. The problem is that 0.0.0.0 is a special IP address which refers to "This host on this network" (RFC 1122, 3.2.1.3a), although it isn't the address of any of the interfaces on a host. According to Paul Vixie in the comp.protocols.tcp-ip.domains FAQ (Q5.15): 0.0.0.0 is just an alias for the first interface address assigned after a system boot [ ... ] The IP stacks I've checked (Solaris and Linux) behave consistently with this. Because qmail doesn't recognize 0.0.0.0 as an IP address which refers to the local host, when it sees an MX record with that address, it doesn't recognize it as being an address that will connect back to itself. This causes the looping scenario that ipme is designed to prevent. The simple solution to this problem is to add 0.0.0.0 to ipme, by adding something like: ip_scan("0.0.0.0",&ix.ip); if (!ipalloc_append(&ipme,&ix)) { close(moreipme_fd); return 0; } into ipme.c, around line 96. The solution we actually used took advantage of an internal patch which allows us to list additional addresses to be added to ipme in "control/moreipme", which works around some other problems qmail has when addresses that refer to it go through any kind of address translation or proxying, and it can't recognize them as local. We just added 0.0.0.0 to the beginning of this file, and all was well. I'd be happy to hear any comments on this problem. -----ScottG. To: qmail@lists.cr.yp.to Subject: Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or127.0.0.1) From: "D. J. Bernstein" Date: Thu, 25 Jan 2001 22:18:11 +0000 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