Re: [Exim] $interface_host ?

Inizio della pagina
Delete this message
Reply to this message
Autore: patl
Data:  
To: Philip Hazel
CC: exim-users
Oggetto: Re: [Exim] $interface_host ?
On 13-Mar-00 at 02:02, Philip Hazel (ph10@???) wrote:
> On Sat, 11 Mar 2000 patl@??? wrote:
>
> > That would handle some of the things I want to do; but I also want
> > to be able to insert it into file paths; so a separate variable
> > would probably be more generally useful. (I'm assuming that if
> > there were an $interface_host variable, it would be possible to
> > use 'qualify_domain = $interface_host' and similar constructs to
> > effectively replace primary_hostname wherever desired.)
>
> Ah! Possible problem here. A host may have many interfaces, and there
> are people who want to use different interfaces for different types of
> outgoing message. That is why "interface" is in the smtp transport
> rather than being a global option. You could have different transports
> that used different interfaces.
>
> qualify_domain is not an expanded variable; it is one of the basic bits
> of data for the configuration.


Hmm. I knew it was global and processed fairly early; but I was
hoping it would expand once.

> I think I'm still not clear as to exactly what you want to do here. Is
> it that you just want to set a single IP address for the outgoing
> interface, and have the hostname obtained from this value rather than
> the current means, or is that too simple? I can't see any use for a
> variable unless it is going to vary! If it isn't going to vary, then a
> macro can be used.


I am an Internet Presence Provider, but not a full ISP. I
provide virtual host/domain services (HTTP, FTP, SMTP, IMAP,
POP, etc.), which are accessed through whatever ISP the client
finds most convienient. (Not having dial-ups closes a number
of potential security holes; and allows us to concentrate
our services on the needs of small businesses and non-profit
organizations.) I have a separate directory to hold config
information, mailboxes, and the FTP and HTTP areas for each
virtual host. The directory names are based on the virtual
host/domain names.

I have IP-based virtual hosts. Ideally, incoming connections to
a virtual host's IP address would be greeted with that host's FQDN
rather than the primary_name for the real host. I would also like
to allow authenticated customers to relay through their virtual
host so that the mail appears to originate there rather than at
their ISP.

I'm using Cyrus for the IMAP/POP service; and have set it up to
have separate namespaces and storage areas for each virtual host.
Given the FQDN of the virtual host, (or just the domain part without
the hostname), I can easily pass this to the Cyrus deliver program.
The difficulty, currently, is cleanly determining what that should
be. I could just use the interface_address and make symlinks; or
build a database for address to name lookups. But either of those
could get out of sync with the DNS database; and they both add a
bit of extra work in setting up and maintaining the virtual hosts.
An interface_host variable would provide the cleanest way for me
to do obtain the proper hostname. A DNS lookup method that took
both the key and the record type would be almost as clean; and more
flexable.

> > I'm on a rush job right now; but when it is over, I may try to
> > implement this myself (and submit patches). Is there an easy
> > way to tell if the variable is actually used in the config file
> > so that we could avoid the overhead of the DNS lookup if it
> > isn't used? Will the right place for the lookup be fairly obvious
> > when I start digging through the code. (Base that answer on the
> > assumption that I'm a fairly senior software engineer...)
>
> I can't really answer that because I'm not exactly sure what you are
> trying to achieve. If there were a variable that was set by DNS lookup
> from some IP address -- and at present there isn't such an IP address
> except in the smtp transport -- then it could be coded to do the DNS
> lookup the first time the variable was used.
>
> Hmm. Wait a minute. You are talking about inserting the value into file
> paths. That must mean you are talking about *incoming* messages, and
> I've been thinking all the time about *outgoing* messages, which are
> different. Of course, $interface_address is already available - clearly
> $interface_name could be added. However, getting it to override
> qualify_domain would be a different matter.


Adding inteface_name, valid when interface_address is valid, would
certainly solve most of my problem with incoming messages.

In my case, outgoing messages for virtual domains will (almost)
always originate on a different host; and would always require
a TCP/IP SMTP connection between the originating MUA and exim.

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.

Hmmm. As I review the docs, I see that unqualified senders and
recipients should only be accepted for locally generated mail;
so this shouldn't be an issue for me. (I have occasionally seen
mail from one user to another within a virtual domain get stuck
in the queue because it qualified with the primary_hostname
instead. The mechanism for those must be more subtle than I
thought. Perhaps they were all sent via Web pages...)

It would be nice to have a mechanism to allow AUTHenticated senders
to qualify sender and recipients with the interface hostname; but
I'd give that a much lower priority than the other virtual domain
support capabilities.


-Pat