Scott Gifford <sgifford@suspectclass.com> wrote:
>Running "ipmeprint" from the qmail source directory is a more reliable
>way of finding out what qmail thinks your IP addresses are; a
>difference between its output and what you expect could point you to
>the problem.
No change:
# ./ipmeprint
127.0.0.1
160.91.218.105
#
>Were there any changes in the network, DNS, or OS?
There are network/DNS changes made all the time. I'm not always made
aware of the changes when they're supposed to be transparent,
though. I've upgraded my OS a couple times since installing
multilog-watch, but they never broke it.
>Some examples of
>things that could cause qmail-remote to be willing to connect to
>itself in the past:
>
> * sws5.ornl.gov pointed to another IP address, like an outside
> redirector or NAT router.
I used to have an MX for sws5, but I removed it months ago.
> * Split-horizon DNS caused your qmail server to see an IP address
> other than its own for sws5.ornl.gov.
Nope.
> * Your mail server wasn't able to detect all of its network
> interfaces properly.
Nope. Just the one interface.
>You really don't want the circumstances that make it work, though; if
>qmail-remote is willing to deliver to itself, you can get mail loops
>if somebody sends mail to a domain that is pointed to your IP address
>but your mail server doesn't recognize as local.
But qmail-send makes that determination, not qmail-remote.
>Something that can handle both local and remote mail, like
>qmail-inject, is really what you want to use here. Is there a reason
>you don't want to?
No, not at all. Like I said, I'm using Russ Allbery's
multilog-watch--for almost five years now. I don't know why Russ used
qmail-remote. I also don't know why it worked fine on two systems for
years and broke recently on both due to some change I haven't been
able to track down. I've got a workaround so it's just a puzzle at
this point.
-Dave
|