Ahoj,
Dňa Sun, 1 May 2022 11:54:32 +0100 Jeremy Harris via Exim-users
<exim-users@???> napísal:
> On 30/04/2022 12:04, Slavko via Exim-users wrote:
> >> That's worthy of consideration; thank you for the idea.
> >> Essentially, it would be treating a backend MTA as a trusted DB
> >> for lookup.
>
> Committed at 7bdf04110b.
Thanks, from the docs in that commit it looks as exactly what i want,
only things what is not clean from it is: will be appropriate $*_data
variables filled on defer result with defer_ok option? I mean in case,
when callout do not fail due network errors. I expect that no, but to
be sure.
I do not know if that will be useful, i only want to know it.
> > can you consider in that "trusted DB" something,
> > which can interpret deffer responses?
>
> I'm not sure what you're wanting here that isn't already
> present; if the callout gets a 4xx then the ACL should
> defer. What "interpretation" are you looking for?
Sorry if i was not clean, my English is not best, i will try to be more
descriptive (all is about local recipient callouts to other own MTA)...
Yes, ACL deffer on temporary error, but one cannot distinguish on
that deffer, if it was due network/server error or it is defer response.
Currently there are two (beside other) possibility:
+ without defer_ok, on any defer reason the ACL immediately returns
defer result and one cannot act on it (except warn)
+ with defer_ok, that condition is true on any defer reason and ACL
continues to next condition(s)
The second looks OK at first, but to distinguish if that defer happens
due network error or as real MTA response, one have to parse
$acl_verify_message, if recipient is valid, but defers (for some
reason), or recipient status is unknown because defer happens eg.
because remote MTA is down. While it is OK (for me) to defer in both
cases, i want to send different message.
The $*_verify_failure variables, by docs, are not usable on defer
response (with defer_ok), as its value is set (mostly) at reject
(recipient).
Yes, there are recipes how to distinguish temporary/permanent errors
from that callout by the warn(s) verb, but these are not compatible
with no_cache (in mean, that callout is done multiple times then), and
still cannot distinguish network vs. real temporary errors.
In retry rules i can distinguish connection failures from recipient
failures and i want something as that (while not as precise), i want to
know, if it is network error (configuration error, DNS error, etc), or
it is real result of recipient verification, thus recipient is
verified, but it doesn't accept messages for now.
I do callout twice, once on inbound MX to check recipient address on
remote MSA. That remote MSA know only about aliases, real user DB is
maintained by dovecot, thus i use second callout to dovecot to verify
it. The dovecot itself is responsible for quotas too and it is able to
return temporary error response on quota excess, but i cannot use it,
as i cannot (simple) distinguish network errors from that quota.
IMO, sufficient solution can be, if the $*_verify_failure variables will
at least have their defer counterparts for mail & recipient values, eg.
mail_defer, recipient_defer.
I hope that now it is more clear now...
And BTW, the $acl_verify_message is horrible, and i cannot use it
directly, as i do not want to tell random remote connections, that i am
doing callout and do not want to message have two codes. To extract
message only from it i have to use (but i afraid, that this sg{} will
fail for multiline responses):
${sg {$acl_verify_message}{^Callout verification failed:\\n\\d+ }{}}
regards
--
Slavko
https://www.slavino.sk
