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: MarkdV
CC: exim-users
Assunto: Re: [exim] mail relay - null or empty Envelope Sender problem...


--On 25 August 2009 13:53:31 +0200 MarkdV <markdv.exim@???> wrote:

>
> Ian Eiloart wrote:
>>
>> --On 21 August 2009 18:56:13 +0200 MarkdV <markdv.exim@???> wrote:
>>
>>> Ian Eiloart wrote:
>>>> --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
>>> No, that first one should be c _and_ d true. You said it yourself, "if
>>> _all_ conditions are true".

>>
>> quite right, it should be. Or. "! (c or d false)"
> >
>>>> I think it's equivalent to nesting, like this:
>>>> accept condition a
>>>>        condition b
>>>>     deny
>>>>         ! condition c
>>>>         ! condition d
>>> So, no... More like:

>>>
>>> accept condition a
>>>         condition b
>>>      require
>>>         condition c
>>>         condition d

>>
>> No, because "require c, d" passes when c or d are false. "deny !c, !d"
>> denies when c or d are false.
>
> IMHO what endpass does now resembles "require", because like require it
> requires all conditions to be true otherwise it will reject. That's why I
> thought require instead of deny.
>
> deny
> ! cond c
> ! cond d
>
> Will only deny if both c and d are false. Where endpass as we know it
> will cause a deny if either of the conditions are false. See what I mean?
>
> "!c and !d" is not the same as "!(c and d)". The former is what your deny
> does, the latter can't be done with deny but is what require does.


Right, "!c and !d" == "!(c or d)", which is why I negated those two
conditions. But you're right about require. "require !a" == "deny a", so
"require (c and d)" == "deny (!c or !d)"

So, I think I prefer your suggestion since it uses less logical negation.

>> It should do what accept...endpass does.
>
> Hmm.. wait. Maybe I misunderstood you, are you talking about a different
> kind of modifier(s) for accept only? Or allow those modifiers to also be
> applied to other statements (deny/require/warn)? I thought you meant the
> latter...


I was discussing both ideas, I think. "endpass" is only valid with
"accept". So, a replacement is only required to work with "accept".
However, a more general solution might be desirable. I guess that with a
general solution, one could use require or deny depending on whether the
condition is naturally positive (list membership) or naturally negative
(list non-members).

>> The problem is not the behaviour
>> of endpass, but the poor self-documentation that results from the lack
>> of clarity in meaning.
>
> Agreed there. ;)
>
> Cheers,
> Mark.




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