On Tuesday, June 5 at 09:36 AM, quoth Dave Sill:
So my guess would be that you have a DNS issue: your machine either
thinks its IP address is not 160.91.218.105 (unlikely, but worth
checking), or it thinks that sws5.ornl.gov's MX record resolves to
something other than that (e.g. it could resolve to 127.0.0.1).
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:13:72:1D:0A:62
inet addr:160.91.218.105 Bcast:160.91.219.255 Mask:255.255.252.0
inet6 addr: fe80::213:72ff:fe1d:a62/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:30484331 errors:0 dropped:0 overruns:0 frame:0
TX packets:53802584 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:653996188 (623.6 MiB) TX bytes:636196097 (606.7 MiB)
Interrupt:177
$ dnsmx sws5.ornl.gov
10 sws5.ornl.gov
$ dnsip sws5.ornl.gov
160.91.218.105
$
I still don't get it.
OH! Right, duh.
Here's what I *think* is going on:
So, qmail-remote *does not* read control/locals. Which makes this
error message very strange if you consider qmail-remote as a
standalone program. But of course, it's not a standalone program, and
it expects that when it is run, certain things have already happened,
namely, that qmail-send (which *does* read control/locals) has already
made the local/remote decision, and has determined that the recipient
host is not local (and is therefore remote).
What qmail-remote does, then, is it looks up the recipient host's
address, and then asks itself "is this recipient host actually ME?"
(i.e. is it this machine?) If qmail-remote determines that it IS being
asked to deliver to itself, it spits out the error that you're seeing.
What qmail-remote assumes is going on is that qmail-send decided that
hostname X is remote (i.e. it wasn't in control/locals) and so told
qmail-remote to deliver to it; but qmail-remote realized that hostname
X is actually pointing to the local machine, and thus if it continued
with the delivery, it would be perpetrating a mail loop (i.e.
qmail-send would once again determine that that hostname is non-local,
and qmail-remote would get it again, and would deliver it to localhost
again, etc.). And the only way that could happen, of course, is if
hostname X isn't in control/locals (or, technically,
control/virtualdomains), which is why qmail-remote spits out that
particular error!
So I guess the question then becomes: why are you using qmail-remote
to inject mail into the local queue? The command:
qmail-remote localhost me@localhost me@localhost
should instead be written:
qmail-inject -fme@localhost me@localhost
or in your case:
qmail-inject -froot@sws5.ornl.gov root@sws5.ornl.gov
The only remaining question after that becomes: why did the (logically
incorrect) qmail-remote command work for you *before*? I can think of
only two possibilities:
1. qmail-remote wasn't correctly identifying itself
2. you used to have an entry for sws5.ornl.gov in smtproutes
(which I believe overrides this particular check)
Does that make sense?
~Kyle
--
Democracy must be something more than two wolves and a sheep voting on
what to have for dinner.
-- James Bovard
pgpHu4mUda7Ja.pgp
Description: PGP signature
|