Re: [exim] mail relay - null or empty Envelope Sender proble…

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Ian Eiloart
Data:  
Para: Jethro R Binks, exim-users
Assunto: Re: [exim] mail relay - null or empty Envelope Sender problem...


--On 20 August 2009 16:32:40 +0100 Jethro R Binks
<jethro.binks@???> wrote:

> On Thu, 20 Aug 2009, Todd Lyons wrote:
>
>> Why is it an accept? That whole endpass thing just never really made
>> a whole lot of sense to me. Every time I have a case where I need to
>> use it, I have to study the docs and figure it out step by step. It's
>> not a natural thought process, and for some reason the knowledge
>> doesn't stick around after I've implemented it. I'll just assume that
>> I'm getting old and just can't remember crap anymore...
>
> If it's any consolution, I made similar grumbles to PH a few years ago
> about endpass, I always struggled to get my head around it, and like you,
> had to keep re-reading the docs. He didn't disagree that it was
> non-intuitive and awkward. :)


so, according to the docs, endpass can only be used in an accept statement.

accept condition a
       condition b
       endpass
            condition c
            condition d


will either accept, deny or pass. It'll accept if all conditions are true.
It'll pass if a or b are false. It'll deny if a and b are true, but c or d
are false.


               a and b    !(a and b)
c or d true:     accept     pass
c or d false:    deny       pass


I think it's equivalent to nesting, like this:
accept condition a
       condition b
    deny
        ! condition c
        ! condition d


               a and b    !(a and b)
c or d true:    accept       pass
c or d false:   deny         pass



is that true? if so, it might be a neater, and more general solution, to
allow nesting of statements like this. Some additional syntax would be
required to distinguish a nested statement from a following statement.
Perhaps, like this:

accept condition a
       condition b
    but deny
        ! condition c
        ! condition d


This would be simpler on two counts. First, the nesting could be used in
any statement, not just "accept". Second, it would avoid the mental
contortions involved in remembering that the alternative verb changes after
endpass - with my syntax, the implicit alternative verb is the verb of the
outer statement.

Of course, this could be confused with the existing nesting mechanism,
which allows conditions like "acl = ...". When an acl nested like that
returns "deny", it's simply causes the current statement to pass. So, I
might be proposing an unholy mess here.

A simpler solution, requiring less coding but more social engineering
(education). Just remember that endpass means "but deny if". Perhaps a
synonymous keyword "butdenyif" could deprecate "endpass"?



> Jethro.
>
> . . . . . . . . . . . . . . . . . . . . . . . . .
> Jethro R Binks
> Computing Officer, IT Services, University Of Strathclyde, Glasgow, UK




--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/