Re: [exim] alternative to local_part_suffix in ACL?

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Chris Knadle
Data:  
Para: exim-users
Assunto: Re: [exim] alternative to local_part_suffix in ACL?
On Wednesday 01 February 2006 08:08, Marc Sherman wrote:
> Chris Knadle wrote:
> > What I would like to do is something similar to this:
> >
> >   accept
> >     local_parts_suffix = -*
> >     condition = ${lookup ldap {ldap://localhost/dc=example,dc=com??sub?\
> >                  (|(mailLocalAddress=$local_part_prefix@$domain))}
> > {yes}{no}}

>
> Two options:
> 1) use $sg in the ACL statement to remove the suffix using a regex


Listing this as well as the relevent chapter greatly helped. I've
implemented this, which does what I was looking for:

  accept
    domains = example.net
    condition = ${lookup ldap {ldap://localhost/dc=ofobscurity,dc=com??sub?\
                 (|(mailLocalAddress=${extract{1}{-}{$local_part}}@$domain))
             {yes}{no}}


Examples:
Marc-Sherman@??? -> looks up Marc@???
Marc.Sherman@??? -> looks up Marc.Sherman@???

This is the behavior I wanted.

> 2) set address_data in the router where you use local_parts_suffix, and
> use $address_data in the ACL after recipient verification


The reason that I don't want to do this in a router is that I am trying to
do these checks during the initial rcpt checks, before the contents of the
message is ever sent. This avoids generating unecessary bounce messages
resulting from an address failure during the router. [I don't want to be a
source of backscatter.]

> The second feels cleaner to me -- it puts all the address manipulation
> in the router where it belongs, so if you change your suffix logic, you
> only have to change it in one place.


I agree that that's normally where the address manipulation should be, and
I also agree that having the suffix logic in one spot is also desirable. At
the same time, I don't want to accept messages that I know I'll later bounce
or reject, and I have to live with this administrator's choice of using these
wildcard email addresses, which aren't such a great idea, in my opinion. I
now have a way of living with these and yet having a policy of default-deny,
which is what I wanted.

Marc, thank you very much. I have what I think I need.

    - Chris


--

Chris Knadle
Chris.Knadle@???