Hi
Firstly, please don't obfuscate your posts:
http://www.exim.org/eximwiki/MailingListEtiquette
It makes things easier to debug if you give us the exact
information/errors you are receiving.
On Sun, 2006-12-31 at 18:01 -0800, Jim McCloskey wrote:
> I take care of a small group of workstations/servers running Debian
> testing. The machines run exim 4.63 as packaged for Debian.
Depending on which configuration system you're using, you may have to
direct your question to the Debian support resources (see the relevant
README that comes with your package). But we'll come to that if it's
necessary.
<snip error message>
> I know what the error message is telling me, and I understand why
> delivery to literal IP addresses is disabled by default in exim. But I
> don't understand why literal IP addresses are being used for delivery
> attempts in the first place. The test messages I have sent from various
> machines are addressed in the normal way to user@???; they are
> not addressed to user@123.456.789.10.
No, but somehow they're getting converted to that when Exim runs through
its' recipient verification stage.
> And what puzzles me most is the fact that the configuration of exim
> v.4 on the machine which bounces mail is exactly the same as the
> configuration of exim v.4 on the other machines, all of which deliver
> mail from other machines without complaint.
The configuration file(s) can be identical - but what about the data
files/databases the configuration queries? Looks to me like you have
some alias table or other lookup table which is aliasing your users like
so:
name@???: name@[123.456.789.10]
But we won't know that until you post some unobfuscated details... can
you run (on the affected machine, and substituting real addresses/IP
addresses as appropriate):
cat <<EOF | exim -d -bh 1.2.3.4
EHLO real.fqdn.name
MAIL FROM:<realname@???>
RCPT TO:<name@???>
<CTRL-D>
That runs a test SMTP session as though it originated from 1.2.3.4, and
dumps lots of debug info. It should show you, if you work through it,
where the addressing changes from the one you expect to the one that
breaks.
We can look at the config after that. If you need a little more help,
consider posting the debug output (sanitised if you have things like
MySQL passwords in it, but otherwise untouched)
Graeme
