Subject: [dmarc-ietf] Trying to understand DMARC in light of Sender/indicators

From: Brandon Long <[email-masked]>
Date: Tue, 29 Sep 2020 18:56:33 -0700

Although I'm not fully convinced by Dave's point on whether indicators are
useless (they certainly are not of large value, I'm less certain in the
margins).. I think I need to work through what DMARC is without that.

DMARC is composed of three things: alignment, policy and reporting.  I
think the argument is that the most important thing that DMARC brings is
message authentication.. but that's not actually what DMARC brings, but
perhaps we can view the point of DMARC as pushing forward the authenticated
message agenda.  In some ways, it's well defined to be such a forcing
function.  Policy and alignment make it easy for various bodies to point to
it as something they require entities to do, and reporting gives them the
path to do it and measure their success against it.

Alignment makes policy application easy, and it also makes reporting easy.
The Sender proposal hijacks the alignment, bringing in another
possible policy to enforce and a different potential reporting path.  The
draft makes it clear which policy is enforced (though of course that only
works if the receiver supports the Sender extension), but various folks on
the list have referred to the matrix problem of looking at the policies of
both, so at least it brings confusion.  It does provide confusion of
"ownership".  DMARC currently provides very clear ownership, even if that
is overly simplified for the pre-existing ecosystem.  Adding Sender muddies
that, even if it is a better match.

If both Sender & From fail evaluation, do we report to both? Should we
report Sender overrides to the From, should we report which From we're
overriding to the Sender?  How does the Sender overrider benefit from
reporting?  They'll have even less opportunity to "fix" things, since
presumably they have a more straightforward role, and without the existence
of the header, they have no role at all, so the best it could be is "places
we add the header but fail to sign" or all the other normal intermediary
cases where DMARC currently fails.

Does DMARC that allows third party overrides via Sender provide the same
incentive to originators?  In the sense that it makes it easier to get to
p=reject as there are fewer false rejects, probably.  In the sense that it
undermines the simple explanation for what DMARC does, I think it will harm
DMARC adoption.  ""Why did this phishing message get through" "Because
example.com added a Sender header that's aligned"  "What's the point of me
doing all this if it can be bypassed that easily?" "See, the receiving
system knows it wasn't yours and so it's on them that they didn't catch it"

In some ways, I fear that the Sender proposal is a solution for the mailing
list problem that throws out almost everything that DMARC added.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Tue, 29 Sep 2020 19:04:44 -0700

I should also add, that making Sender a standardized local policy override
(like ARC), we could expand the reporting to include that, allowing those
who ingest reports to help explain it to admins and highlight various
things about the Sender... this could assuage some of the admin
understanding issue.

Brandon

On Tue, Sep 29, 2020 at 6:56 PM Brandon Long <[email-masked]> wrote:

> Alignment makes policy application easy, and it also makes reporting
> easy.  The Sender proposal hijacks the alignment, bringing in another
> example.com added a Sender header that's aligned"  "What's the point of
> me doing all this if it can be bypassed that easily?" "See, the receiving
> In some ways, I fear that the Sender proposal is a solution for the
> mailing list problem that throws out almost everything that DMARC added.
>
> Brandon
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Sep 2020 07:05:29 -0700

On 9/29/2020 6:56 PM, Brandon Long wrote:
> Although I'm not fully convinced by Dave's point on whether indicators 
> are useless (they certainly are not of large value, I'm less certain 
> in the margins)

I fully appreciate (and actually share) the emotional attachment to the 
belief that this is somehow useful for recipient decision-making, but it 
lacks any meaningful objective support.

Show me studies that demonstrate efficacy.  And explain away the ones 
that don't.

It took awhile for people to accept that the Earth is not the center of 
the universe.  We seem similarly stuck here.

> .. I think I need to work through what DMARC is without that.

+1

> DMARC is composed of three things: alignment, policy and reporting.

+1

> I think the argument is that the most important thing that DMARC 
> brings is message authentication.. but that's not actually what DMARC 
> brings, but perhaps we can view the point of DMARC as pushing forward 
> the authenticated message agenda.

It is certainly taken as essential.

But it isn't clear what you mean by "pushing forward the authenticated 
message agenda".  I can guess, but it's taking as a given something that 
has not been stated clearly and does not have any obvious documentation 
as support.

(Also, I'll anticipate the clarification and suggest that the agenda is 
actually accountability, where authentication is a mechanism to aid it. 
This is more than vocabulary quibbling.  It suggests a different focus 
that might permit more useful discussion about means and alternatives.)

> In some ways, it's well defined to be such a forcing function.  Policy 
> and alignment make it easy for various bodies to point to it as 
> something they require entities to do, and reporting gives them the 

Reporting does more than that.

(And fwiw, from the start, I've felt that the reporting capability was, 
by far, the most important feature of this work.)

> easy.

+1

> The Sender proposal hijacks the alignment,

So does re-writing the From: field, but you appear to find that 
acceptable.  Why?

> bringing in another possible policy to enforce and a different 
> potential reporting path.

ibid.

> The draft makes it clear which policy is enforced

No it doesn't.  Again, I suspect you are working from the original 
draft, rather than the current one.

> (though of course that only works if the receiver supports the Sender 
> extension), but various folks on the list have referred to the matrix 
> problem of looking at the policies of both, so at least it brings 
> confusion.  It does provide confusion of "ownership".  DMARC currently 
> provides very clear ownership, even if that is overly simplified for 
> the pre-existing ecosystem.  Adding Sender muddies that, even if it is 
> a better match.

For any filtering engine that is not simplistic and mechanical -- which 
is any competent engine that is competently operated -- The current 
DMARC merely adds a signal, rather than a trivial means of resolution, 
and adding more signal does not 'muddy' anything.

> If both Sender & From fail evaluation, do we report to both?

Possibly.  So?

> Should we report Sender overrides to the From,

There are no overrides.  So this characterization is meaningful.

But since I can see a possibly-interesting point lurking here, I'll 
offer a re-casting:

    If both Sender: and From: have domain names subject to DMARC
    processing, and one succeeds while the other fails, what, if any,
    reporting should be made to the one that failed?

My quick reaction is that it would be appropriate and useful to report 
the failure to the domain owner AND to indicate the alternate domain 
name that succeeded.

> should we report which From we're overriding to the Sender?

What do you mean "which From"?

If you meant which Sender: domain succeeded, where the From: failed, 
then I believe yes, it could be useful to report that.

> How does the Sender overrider benefit from reporting?

What does this question mean?  I don't understand it.

> They'll have even less opportunity to "fix" things, since presumably 
> they have a more straightforward role, and without the existence of 
> the header, they have no role at all, so the best it could be is 
> "places we add the header but fail to sign" or all the other normal 
> intermediary cases where DMARC currently fails.

I don't understand this, either.  At the least, the references in it are 
too vague.

> Does DMARC that allows third party overrides via Sender provide the 
> same incentive to originators?

Does From field re-writing provide the same incentives?  Why or why not?

> In the sense that it makes it easier to get to p=reject as there are 
> fewer false rejects, probably.  In the sense that it undermines the 
> simple explanation for what DMARC does, I think it will harm DMARC 
> adoption.

The simple explanation of what DMARC does is classically Procrustean.  
It's simple only if one constrains things quite a lot.

> mailing list problem that throws out almost everything that DMARC added.

Do does From: field re-writing.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net