Jakob Hirsch wrote:
> On 28.10.2011 11:07, W B Hacker wrote:
Jakob, had this been written in Deutsch, I'd not be presuming to tell
you about *my* dificulty understanding that language.
>
>
>> A triggered 'accept' is not 'permanent' until end of DATA. Period.
>> A triggered 'deny' class verb is 'permanent' AT ONCE. WHEREVER it is.
>
> btw, your terminology is (at least) uncommon, escpecially for email.
> "permanent" and "temporary" are not quite appropriate to describe what
> "accept" and "deny" do. But let's not get picky about that.
>
>> An 'endpass' is not needed by an 'accept', but is harmless and supports
>> consistency in style w/r slef-diocumenting 'reminders' of what is taking
>> place.
> ...
>> Circumstances may be better suited to a 'warn' that has to ascertain
>> things AND report them AND action others AND manipulate things - that do
>> not (yet) give rise to a deny, nor (yet) a 'final' accept - but may
>> have no further need for wasting resources in traversing the *remainder*
>> of the acl test clauses in a given phase.
>>
>> Far easier to use an 'endpass' and rely on a stand-alone 'accept' at the
>> END of each phase to otherwise onpass the 'survivors'.
>
> As I understand you nebulous words and the line from you previous posting:
>
>> 'endpass' after an 'accept' can skip all remaining clauses in a given phase.
>
Endpass after *anything* can so skip.
> I have to say: This is nonsense. "endpass" can turn an "accept" into a
> deny, but this has nothing to do with "skipping the remaining clauses of
> a phase". "accept" already does that. With or without "endpass".
Yes, it happens that 'accept' carries it inherently, but no harm is done
- for sake of consistency in style - in applying it to 'accept' as well
as other needfuls.
As I said ... So far, we agree in substance - even though you have
twice contradicted yourself.
> "accept" means, the ACL is finished successfully and that no more stanze
> of the ACL will be evaluated.
>
Semantics. As I said, we STILL agree.
> Let me show you what "endpass" really does. First, "accept" without
> "endpass":
>
> accept
> condition = some_condition
>
> could be written with pseudo code as:
>
> function acl_check_connect {
> if (some_condition) {
> return true; // accept!
> }
> ... // other stanze
> }
>
Why add confusion?
accept
IF match exit
ELSE continue
ENDIF
> Now with the use of "endpass"
>
> accept
> condition = some_condition
> endpass
> condition = ep_condition
>
> would be in pseudo code:
>
> function acl_check_connect {
> if (some_condition) {
> if (ep_condition) {
> return true; // accept!
> } else {
> // failing endpass condition turns "accept" into "deny"
> return false;
> }
> }
> ... // other stanze
> }
>
Painful, that pseudo code...
> Or, in a table:
>
> some_condition | ep_condition | action
> ---------------+--------------+--------
> false false go to next stanza
> false true go to next stanza ("endpass"
> does not matter)
> true false deny
> true true accept
>
>
> Hope it's clearer now...
>
It was never in doubt HERE.
Not 'til you complexified it, anyway.
But if you need Pseudo-DeMorgan to clarify it THERE, feel free...
>
>
> PS: Oh, and btw, a "deny" does not necessarily "terminate a session", as
> you wrote. If there are multiple recipients, you can "deny" all of them
> but one and still get a message delivered.
>
Point taken. And certainly germane.
But IF/AS/WHEN there *are* multiple recipients, the machine is iterating
over them - one at a time in RCPT_TO, as a no-longer-severable 'block'
(ONE pass) in DATA.
The underlying logic is the same for each go.
IF/AS/WHEN one or more do NOT give rise to deny, then the edn result is
NOT 'deny', *for the phase OR the session*.
A 'deny' that is EITHER 'sole' 9one recipient) OR just 'last one
standing' (en-bloc in DATA) OTOH, is .. final.
There is no such animal as an:
'Oh, wait, come back! I know that user after all!'
smtp phase.
Even with greylisting, one has to wait for far-end to retry.
You can't use suction.
Bill
--
韓家標
