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

[Brandon Long <[e-mail]>]

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 <[e-mail]> 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 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
>