Re: [EXIM] Exim configuration

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Toralf Lund
Dátum:  
Címzett: Philip Hazel
CC: exim-users
Tárgy: Re: [EXIM] Exim configuration
Philip Hazel wrote:

> On Thu, 18 Mar 1999, Toralf Lund wrote:
>
> > > Put the valid domain names in a file (or dbm file) and use a
> > > lsearch/dbm lookup to match them. This can also be used in the rewrite
> > > rule. Cleaning up can be completed by using a macro at the top of the
> > > file for local domains and just using that in the rest of the file.
> >
> > Is it really not possible to search a colon separated list?
>
> I didn't pay much attention to the earlier exchange. You can certainly
> search colon-separated lists in Exim in many places, but not on the LHS
> of rewrite rules, I'm afraid.


Too bad. Can I store the regular expression in a variable and use it to generate
a colon separated list _AND_ the LHS of a rewrite rule? (I'll have another look
in the manual here...)

>
> > > The only thing I would do is have a process that builds an alias file
> > > from appropriate passwd entries.
> > I may be fuzzy, but this is exactly the kind of thing I'm trying to avoid.
> > I want to use Exim to make life simpler, remember.
>
> You surely don't want Exim to do a linear search of your passwd file
> every time it receives a message, do you? (Or maybe you just have a
> dozen people in it?) It can't be very difficult to write a Perl script
> to build an alias file automatically and run it every time you update
> your passwd file. This will be *much* more efficient when the passwd
> file gets big. It also means that when you change from using a passwd
> file to NIS, NIS+, LDAP, or whatever for managing your users, you just
> have to replace the alias generator - you don't have to fiddle with
> Exim.
>


I don't know exactly how 'finger' etc. handles this, but the operation is
transparent with respect to whether NIS is used or not, and speed does not seem
to be an issue. We don't have that many users, but far more than a dozen. Also,
I can't see how a new alias file would make the search that much more efficient,
as this would grow be nearly as large as the password file. The search may be
speeded up if the file is indexed, of course, but there are several ways to make
GECOS searches more efficient, too.

Anyhow, we are using NIS (or is it NIS+ these days?), and I would probably use
ypmake to generate the appropriate files here. Also, a PERL script can easily be
designed so that it doesn't have to be changed if NIS is enabled or disabled. I
still don't like this idea, though.

>
> > The matching doesn't really have to be that fuzzy (unlike me), a direct
> > comparison between full names would do in most cases. We're reluctant to
> > bounce messages unless it is absolutely necessary, though, as it can easily
> > give people the wrong impression. We're in the computing and electronics
> > business, so we certainly don't want to look like we can't set up an
> > e-mail system properly.
>
> It is possible to set up Exim so that any local part that can't be
> recognized will be delivered to some standard address, e.g. postmaster.
> You can do this with a default in an alias file, for example.
>
> > > > similar, but include data from NIS if a NIS include directive (+:+) is
> > > > encountered.
> > >
> > > Add an additional director to do NIS lookups. This looks like another
> > > broken Sun thing - there is no need to emulate that.
> >
> > Not really. I think this is the way NIS was designed to work. Information
> > form passwd and group is looked up in exactly the same way.
>
> Exim's lookups are all separate and modular; there is no way you can
> interlink them. Remember, it can handle any number of different alias
> files - there isn't just one master file. So /etc/aliases is not special
> in any way.
>
> > > Take the standard config you use, set
> > >         local_domains =

> >
> > What will happen if I do this on the "best MX" ?
>
> You will get errors. That setting should be used only on hosts that do
> no local deliveries.
>


It's not an absolute requirement, but it would be neat if we could change the MX
list without having to re-configure Exim, or even set up hosts listed as low
priority MXs so that they try to route mails to the higher priority ones, but
deliver them locally if these are down. How hard would this be?

>
> > > > receiver_unqualified_hosts = localhost
> > >
> > > You are sending to unqualified addresses - exim only allows that from
> > > the local (ie unix command line) injection normally.
> > >
> > > > sender_host_reject_relay_except = 127.0.0.1
> > >
> > > You are injecting via local loopback SMTP, so that needs to be allowed
> > > to relay.
> >
> > I had pretty much figured that out already, but are there any good reasons
> > why these operations aren't allowed by default? In particular, are there
> > any risks associated with relaying from localhost?
>
> If they were allowed by default, there would have to be ways of turning
> them off for those that don't want them. That would make them into
> special cases. Also, the specification of SMTP states that all addresses
> must be fully qualified; hence the default is to insist on that. Many
> MUAs (e.g. Pine) operate with fully qualified addresses anyway.


Maybe the default configuration file should contain the above settings, with
appropriate comments?


--
- T. Lund




--
*** Exim information can be found at http://www.exim.org/ ***