Re: [Exim] $interface_host ?

On 14-Mar-00 at 00:32, Philip Hazel (ph10@???) wrote:
> On Mon, 13 Mar 2000 patl@??? wrote:
> > Hmm. I knew it was global and processed fairly early; but I was
> > hoping it would expand once.
>
> If you are using a daemon, that wouldn't help! You would need it expanded
> at the start of every incoming message.

Arrgh. I knew I was forgetting something. Too much of my attention
is on my other project right now.

As you have probably guessed, I really don't want to have a separate
daemon for each IP address.

> > Since qualify_domain isn't expanded, perhaps the easiest method would
> > be to add a qualify_domain_use_interface boolean. When true, and when
> > an interface is known, it would override any other specification of
> > qualify_domain and use the interface hostname.
>
> But because there is both qualify_domain and qualify_recipient, it gets
> rather messy. I'll take a look at the uses of qualify_domain. It may be
> that it could be expanded.

Yep. I suspect that in most cases where this is used at all,
qualify_recipient would not be explicitly specified; and would
be expected to take the (overridden) value of qualify_domain.
But to handle the general case, you'd need to add at least
qualify_recipient_use_interface; with it's default value being
$qualify_domain_use_interface.


> > Hmmm. As I review the docs, I see that unqualified senders and
> > recipients should only be accepted for locally generated mail;
>
> ... and also from those hosts specified by {sender,receiver}_unqualified
> hosts ...

Right. Which I'm not using; and probably won't use since my
customers will generally be connecting from dial-up ports of
major ISPs. The paragraph seemed to flow a bit more smoothly
when I didn't bother to mention them...


We've been concentrating on the qualify_domain issue, which is
looking a bit hairy; but that's the least important part of what
I'd like to do for virtual hosting. An interface_host variable,
or other easy way to do a reverse-DNS lookup on $interface_address,
would handle my filename expansion needs. Are there any other places
where it still wouldn't be enough to make a virtual host look 'real'?

It looks like replacing ${primary_hostname} with ${interface_host}
should fix up the HELO/EHLO for both incoming and outgoing messages
to virtual IP addresses. And in the remote_smtp transport I can
set 'interface = $interface_address' to ensure that outgoing relayed
messages use the virtual host's IP address. (Is this safe in the
case of locally generated messages where the interface is unknown?
Will it just fall back to the default, as though I hand't specified
an interface?)


-Pat