Re: [exim] Re: [Exim] Transports

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Richard.Hall
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] Re: [Exim] Transports
Graham,

On Fri, 25 Jun 2004, Graham Dodd wrote:
[...]
> RH> Hmmm ... that implies that you are not using verify=recipient anywhere? If
> RH> you were, you could reject it (for invalid recipients) before it even gets
> RH> as far as SA.
>
> Well I checked in the config
>
> # Accept if the address is in a local domain, but only if the recipient can
> # be verified. Otherwise deny. The "endpass" line is the border between
> # passing on to the next ACL statement (if tests above it fail) or denying
> # access (if tests below it fail).


I recognise that comment ;-) It comes from the default config, and
properly belongs with the second of your 'accept' rules below.

This late in the week, my head can't cope with too much mental exercise,
but I think the problem is with your first rule. From your log line we had

from <roswitha.reischl@???> for www-data@???

so ...

> accept domains = +local_domains : +relay_domains

...presumably OK (falk-ross.de)
>           sender_domains = !+local_domains_sender : !+relay_domains

...presumably OK (stmk.gv.at not local)
>           endpass

...OK
>           verify        = sender

...OK - ie stmk.gv.at will verify
>           message       = unknown sender

...so you have accepted at this point, before reaching the recipient
verification.

You need to turn it around, so that it will reject if verify=sender fails,
rather than accept if it succeeds. The default config has

  require verify        = sender


or equivalently (I think!)

  deny    !verify       = sender


but double-negatives on a Friday afternoon are usually a bad idea :-)

If sender verification succeeds, you will then carry on to reach ...

>   accept  domains = +local_domains
>           endpass
>           message       = Unknown user
>           verify        = recipient

>
> Shouldn't this reject if the user is not known ?


Only if you get this far :-)

HTH,
Richard