On Tue 19/Sep/2023 19:55:02 +0200 Murray S. Kucherawy wrote:
On Tue, Sep 19, 2023 at 8:24 AM Alessandro Vesely <[email protected]> wrote:
My wording can certainly be improved. Before denying the idea, please
consider a couple of facts: >>
1) We want ARC to override DMARC, yet we don't say so. Not in such a way
that, when a receivers does so, he can say he's following the letter of
the protocol. >
Do we need to say that expressly?
I think a protocol ought to specify how it functions as precisely as possible.
Isn't it just another input that a filtering engine could consider?
I don't get that logic. What would such an engine actually do? For example,
add 1 for every black list, add 1 for DMARC failure, 2 if there is a hard
policy, sum the result to SpamAssassin score and reject when it's more than 6?
I don't think adding incomparable values makes sense. SpamAssassin itself,
since I mentioned it, has difficulties at attributing a score to DKIM results.
Indeed, we've been saying for ever that dmarc=pass doesn't mean that a message
is good.
2) Content filtering cannot override DMARC, can it? By "override", I
mean the author domain publishes a hard policy, both SPF and DKIM fail,
and there is no deterministic sign (signature or IP) that the message
comes from a recognized forwarder (including MLs). What kind of content
could ever suggest that a receiver conscientiously overrides DMARC? >
Is that for this document to stipulate?
No, it's not. I asked for an example to understand what we think.
The actual, final logic of an operator's filtering engine is not our affair.
Agreed. However, overriding DMARC policy is strictly our business. Section
5.8 seems to be talking about that, not the final logic. I'm only trying to
make that clearer.
"Other knowledge and analysis", as currently in the draft, certainly
includes content filtering. Do we mean it? Can we think of an example? >
Sure. Think of the opposite case: DMARC passes for spam. Content
filtering absolutely should override the DMARC result.
That's not overriding, inasmuch as dmarc=pass doesn't imply to deliver.
Unless you want to go down the road of proposing that a "pass" should
always win out over any other result while a "fail" should be just one of
many dimensions of analysis, I think the way things are is both correct and
simpler.
In DMARC, p= specifies the policy when authentication fails. We provide no
hints about what to do when authentication succeeds. Although it cannot say
MUST reject, the protocol says that's the intended meaning of p=reject, e.g. in
Section 8.3. However, that's not the whole story. The reason why such a
simplistic directive doesn't work is because of forwarding (including mailing
lists) not because of spam.
Content filtering decisions are independent of authentication. In a correct
multidimensional analysis, any dimension can bring a reason to reject, and
that's not comparable with the results of other dimensions. You don't add
apples and oranges.
DMARC policy overriding is clearly in the same authentication dimension as
DMARC itself, since it's explicitly considered in the I-D. We don't have a
protocol to recognize forwarding (yet), so we cannot tell /exactly/ in what
cases the policy is overridden. However, we mention future developments, so we
can also say what's their scope, can't we?
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
