Re: dmarc damage, was gmail users read on... [bozo subtopic]

[Wei Chuang <[e-mail]>]

On Fri, Sep 12, 2014 at 8:35 AM, MH Michael Hammer (5304) <[e-mail]>
wrote:

>
>
> > -----Original Message-----
> > From: ietf [mailto:[e-mail]] On Behalf Of Christian Huitema
> > Sent: Friday, September 12, 2014 1:34 AM
> > To: Doug Barton; [e-mail]
> > Subject: RE: dmarc damage, was gmail users read on... [bozo subtopic]
> >
> > >>>> I've collected all of the DMARC workarounds I know on the ASRG wiki:
> > >>>>
> > http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_
> > >>>> mail
> > >
> > > Two responses to that, in no particular order of importance:
> > >
> > > 1. So you said, and yet the mere existence of that page out on the
> > > intertubez has (oddly enough) not yet spurred the secretariat into
> action.
> >
> > The big change with DMARC is a deprecation of the Sender/From
> > differentiation, effectively requiring that these two will be the same.
> It
> > seems that big systems have voted that the differentiation causes more
> > harm (spam, phish) than good (remailers).
> >
>
> This is actually not quite true. If the Sender and the From are in the
> same domain then there is no problem. It becomes an issue when the Sender
> and the From are different domains. DMARC does not care about the LHS of
> the email address (whether it is DKIM signing or SPF validation).
>

Agreed, but just wanted to add one thing- doesn't the details of the
whether the sender has to align or not depends on whether SPF or DKIM is
used as the authentication method?  (SPF w/DMARC will force the envelope
sender to agree with from.)  Also I wanted to add to mix that there must be
something by which to lookup the "sender's" DMARC policy, and the DMARC
authors choose for various reasons the FROM domain by which the
authentication methods will enforce "alignment" upon.


>
> > Of the responses listed, the one that clearly works is to ask forwarders
> to
> > forward messages, what the wiki calls "message wrapping." It works in the
> > sense that the mail system sees consistent headers that pass all
> verifications,
> > and represent the actual action of the remailer while not relying on
> > Sender/From differences.
> >
> > At that point, the issue is mostly with the UI. If my reader did
> recognize the
> > "simple forwarding" case from "authorized remailers," then the message
> > wrapping solution would be just fine. The good thing is that it is very
> much
> > under my control
>

I also just wanted to bring another high level idea to the table- rather
than discuss which work arounds to mandate (and all have problems), why not
revisit the authentication methods?  In particular the current DKIM method,
while very powerful in the security sense, is very restrictive.  Any
changes to the signed message parts will cause the authentication to fail.
  For example if a mailing lists modifies the subject or body even if done
so in some sanctioned way, it will fail DKIM.  (And then since the message
is resent, fail SPF)  At the broader IETF community level, perhaps it might
be good to see about improving those RFC's?

For example there are some ideas about improving DKIM out there.  I've made
a general but heavy-handed conceptual proposal early on in the DMARC WG,
and I know there is another one by Murry Kucherawy (list-cannon) that IMO
is a very good direction.  I think there's an opportunity of taking these
approaches and simplifying them to make them palatable to the mailing-list
operators.

-Wei