From: Wei Chuang [mailto:weihaw(_at_)google(_dot_)com]
Sent: Friday, September 12, 2014 1:20 PM
To: MH Michael Hammer (5304)
Cc: Christian Huitema; Doug Barton; ietf(_at_)ietf(_dot_)org
Subject: Re: dmarc damage, was gmail users read on... [bozo subtopic]
On Fri, Sep 12, 2014 at 8:35 AM, MH Michael Hammer (5304)
<MHammer(_at_)ag(_dot_)com<mailto:MHammer(_at_)ag(_dot_)com>> wrote:
-----Original Message-----
From: ietf
[mailto:ietf-bounces(_at_)ietf(_dot_)org<mailto:ietf-bounces(_at_)ietf(_dot_)org>]
On Behalf Of Christian Huitema
Sent: Friday, September 12, 2014 1:34 AM
To: Doug Barton; ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>
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.
MH: Because (DMARC) alignment is required in either case it really isn't an
issue whether SPF or DKIM is used for DMARC validation. Looking up the
"sender's" policy is what PRA attempted in SenderID. I and others showed that
it was rather trivial to game PRA to at least get a neutral status for a
message. There is no reasonable way to establish that the Sender is truly
representing the From, and that problematic when one is talking
security/authorization models. There have been some discussions about how to
implement an "authorization" for Sender but I haven't seen anything that makes
sense to me.
The FROM domain was chosen for DMARC because it is what is generally used in
the MUA (visible to the user). One could just as easily have argued for
MailFrom as long as alignment between the two is required. Six of one half a
dozen of the other.
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?
MH: There is always the potential to consider other authentication methods and
this has been discussed. Initially it is a complexity issue and real world
experience showed that for most use cases (I'm waiting for someone to jump in
and wag their finger at me about MLMs) the combination of aligned SPF and DKIM
validation is extremely effective (although somewhat restrictive). I'm
personally not against someone(s) doing some testing for other authentication
methods to see what the outcomes would be - all you need is at least a
participating sender and receiver. I know that there has been some discussion
of DKIM signing individual MIME parts in addition to an overall signature so
that one could see which parts were modified. This coupled with a signature by
the list/forwarder might be an interesting approach. On the other hand it might
represent too much complexity. Some folks advocate reputation of the forwarder
as the solution. I'm not a big fan of reputation (For me it falls into the
category of "What have you done to me lately" rather than "you've been a good
actor for the last 5 years" - would you accept crap from a good domain gone bad
just because they used to be good?)
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.
MH: I'm agnostic on this. Some advocate changes to accommodate mailing-list
operators - that's fine with me as long as there is still a decent security
model. Others argue that mailing-list operators must change. That may or may
not be true. The mail streams I'm responsible for are typically transactional
and do not go through lists so while have an opinion I've been hanging back
from that "discussion". I'm gratified that there appears to be more serious
discussion in this space though.
-Wei
Mike