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
--
韓家標
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
