[exim-dev] [Bug 677] callout sender verify defer remembered …

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumptes vells: [exim-dev] [Bug 677] New: callout sender verify defer remembered incorrectly as a defer on sender verify
Assumpte: [exim-dev] [Bug 677] callout sender verify defer remembered incorrectly as a defer on sender verify
https://bugs.exim.org/show_bug.cgi?id=677

--- Comment #7 from Peter Gervai <grin@???> ---
I see in the source how it works, if that's where you're heading.

In the testcase there was no Sender:, and From: contained the same address as
envelope-sender. First, verify=sender/callout,defer_ok ran and deferred, in a
"warn" acl, which added warning headers to the email and set acl_m_fakesender,
for later use. Then, later, the check ran which should reject any mail with no
valid sender-field in the header: verify=header_sender.

The problem in the flow is that the latter test should outright reject
("deny"), since it depends on non-callout checks, which are much more strict
(callout is a very sensitive thing nowadays, in an environment of misconfigured
or buggy software, retaliatory dnsbls etc, so callout failures have to be
handled in complately different way and not by "deny" acls).


So, if I understand correctly you say, that
verify = (doesn't matter what's here)
get cached by the address used to verify and the first result, no matter
whether it was a sender or a recipient or something else, no matter what
options were used, and no matter what's the source of the failure (given the
various combinations of the options possible), and it doesn't matter either
whether the admin actually possess the ability to reject this caching.

This doesn't feel proper, and possibly differs from the documentation, too.

--
You are receiving this mail because:
You are on the CC list for the bug.