Re: [Exim] multiple lines of "* ^address$" in sender_reject_…

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Philip Hazel
Data:  
Para: Tor Houghton
CC: exim-users
Assunto: Re: [Exim] multiple lines of "* ^address$" in sender_reject_recipients
On Tue, 11 Dec 2001, Tor Houghton wrote:

>    sender_reject_recipients = @@lsearch*;/etc/exim/reject_file

>
> In "reject_file" I have the following:
>
>    *                       ^savebig$
>    *                       ^mygreencard$
>    *               ^friend$

>
> It seems that Exim only triggers on the first line; that any subsequent
> "match any domain" line is ignored.


It's very odd. It seems that very many people find the concept of
lookups hard to grasp, particular the lsearch one. You are not alone,
Tor. I keep on trying to improve the documentation, but people are
always misunderstanding this concept.

Let me try again:

Lookups work like this: Exim has many different lookup modules. Let's
just concentrate on the simple ones: lsearch, cdb, DBM, and NIS. When it
wants to do a lookup, it throws a "key string" at the module, and gets
back a value which is associated with that key. Like looking something
up in an index.

Now, these are simple indexes: one key <=> one value. You can't have
multiple keys with the same value. Indeed, if you try to do that with a
cdb, DBM, or NIS file, you won't succeed because you can't create
multiple records with the same key. The software won't let you.

lsearch files are of course not pre-processed in any way, so there can
be no check that there is only one copy of a key. What you have done
above is to try to set up multiple records with the same key. In other
words, a malformed lsearch file. If you try to convert this file into a
cdb, DBM, or NIS file, you will get errors. The thing to remember about
all the single-key lookups is that you can always convert between them
without having to change anything (except when you are starting from a
broken lsearch file, of course).

Exim doesn't actually discover that the file is malformed, because the
way it processes an lsearch file is to read through it line by line
until it finds a key that matches. Then it is done. It reads no more.
(It could check, of course, but that seems a huge waste of resources.)

> Is this something that I should have seen in the later CHANGES files,
> or was it never intended to work like this?


The latter.

> (I know I can have them so:
>
>    *    ^savebig$:^mygreencard$:^friend$

>
> but I find it easier to read with multiple lines.)


So write yourself a script that reads a file with multiple lines and
creates a file for Exim to process. Indeed, if you have got lots of
these, consider making a DBM or cdb file while you are at it.

We do it this way, and allow for comments in the original input to
document why and when certain addresses were added to the black list.

--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.