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?
-K
"Do not meddle in the affairs of dragons, because you are crunchy and taste
good with ketchup."
> From: Scott Gifford <[EMAIL PROTECTED]>
> Date: 22 Jan 2001 17:20:49 -0500
> To: [EMAIL PROTECTED]
> Subject: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or
> 127.0.0.1)
>
> Scott Gifford <[EMAIL PROTECTED]> 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.
>
