Re: [dmarc-ietf] Objections to Sender header as override

[Brandon Long <[e-mail]>]

Another issue, I think we should investigate how various systems display
(or not) the Sender header.  My understanding was that Outlook in
particular displayed it, and so encouraging it's widespread use could have
unexpected consequences.

It may be that it already displays it in a way that makes sense in the way
it's used, I think Gmail's display of Sender is (it'll add a "via sender
address" in some circumstances, which seems compatible).

Brandon

On Tue, Sep 29, 2020 at 5:54 PM Brandon Long <[e-mail]> wrote:

> Lacks backward compatibility:
> If we adopt the Sender header as a method to work around DMARC, it is
> obviously a simpler thing to do than ARC, doesn't provide quite as much
> (but what it provides may be sufficient)... but still suffers from one of
> the main issues with ARC, which is that it requires widespread adoption to
> replace some of the other workarounds.
>
> Ie, a mailing list that adopts the Sender header still won't know when it
> can do that over rewriting.
>
> Shouldn't be separate as defined:
> The Sender header proposal is also an adjunct directly to DMARC itself,
> changing the existing dmarc policy evaluation in a direct way.  I don't
> think that should be done by a separate spec, if we do decide to, it should
> be part of the DMARC spec itself, especially so we can explore all the ways
> that it changes the existing spec.  I agree with others who have said that
> adding this makes DMARC not DMARC, though I'm willing to explore that in
> more depth.  I understand Dave's points regarding user level signals, but I
> think alignment benefits in other ways.
>
> If you instead wanted to add it as a separate thing, I don't think it
> should be couched as overriding DMARC like it does, but as the same way we
> expected ARC to override DMARC, as a well defined local policy override.
>
> Really bad third party signing:
> I've objected in the past to various third party signing approaches as
> being non-starters for high value domains.  Google does not use SPF's
> include mechanism, and is not going to list hundreds of possible third
> parties as "ok" for signing to cover all possible mailing lists that are
> employees work on.
>
> In some sense, the Sender override is basically third party signing
> without any actual relationship... which is both good and bad.  It's bad in
> that anyone can now send a phishing message... but I guess anyone could
> have before as well.  It's bad in that we wouldn't say "yes, this is fine"
> for any specific sender... but now we're more at the whim of the receivers.
>
> It's good in that maybe it standardizes a kind of local policy override.
>
> Brandon
>
>
>