Re: [dmarc-ietf] Policy Enforcement Considerations

[Alessandro Vesely <[e-mail]>]

On Tue 19/Sep/2023 19:55:02 +0200 Murray S. Kucherawy wrote:
> On Tue, Sep 19, 2023 at 8:24 AM Alessandro Vesely <[e-mail]> 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
--