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.
