Re: [Exim] multiple alias files and receiver_verify

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Gary Palmer
Data:  
Para: Philip Hazel
CC: exim-users
Asunto: Re: [Exim] multiple alias files and receiver_verify
Philip,

Thanks for you prompt reply :)

Philip Hazel wrote in message ID
<Pine.SOL.3.96.990927100545.29438N-100000@???>:
> On Sun, 26 Sep 1999, Gary Palmer wrote:


> > It seems that the
> > receiver_verify option doesn't recurse until it gets a definitive
> > answer


> Correct. This code goes back well before the days of wild cards in alias
> files. Without wild cards, if the incoming local part matches some
> alias, then that's good enough verification. I can see that with wild
> cards there might be a case for doing more, but the problem then is that
> an alias might expand into several different addresses, and what do you
> do if some of them are OK and others are not? I suppose the most
> straightforward thing is to insist that all of them verify.


How do you handle this at the minute? I see this as a general problem
of SMTP-time validation. e.g. you could have an alias which expands
to multiple local accounts, but not all of them exist. However, you
can't reject the message in the SMTP transaction as there are valid
local recipients.

The wildcard case seems (to me) to be just another example of this
problem (although I don't know the exim internals well enough to know
if its handled similarly). We use two types of wildcards locally.

*@domain -> user@localdomain

or

*@domain -> $local_part@localdomain

Unfortunately, although the latter form is no longer allowed to be
created, we have thousands of legacy ones lying around.

In either case, whatever the `virtual domain' rewriting does, the
local part may not exist. I believe the correct handling of this
would be to return a 550 if none of the aliases exist.

> > Is there any tweak to exim 2.12 to allow the mail for an unknown
> > user@??? to be rejected during the smtp transaction?


> No, and not even in 3.03 (the latest release). However, I will think
> about this wildcard case and see if anything can be done. Thanks for
> pointing it out.


Thanks for all your work Philip.

Gary