Subject: Re: DMARC and yahoo

From: John C Klensin <[email-masked]>
Date: Mon, 21 Apr 2014 02:49:49 -0400

--On Monday, 21 April, 2014 08:26 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> IMO, this is quite elegant.  The Yahoo users continue to get
>> the messages, you don't get cluttered by rejection-related
>> complaints, and those Yahoo users who don't like the digest
>> form can take it up with Yahoo or find other accounts to use.
> 
> Unfortunately they can switch themselves back to normal mode
> too. Digest mode is user-settable, and is very annoying because
> it munges the Subject header. What's really needed is a
> DMARC-safe mode (per subscriber) that optionally rewrites the
> From.

Brian, I think there are several ways to look at this and that
there are some largely separable issues.  One of them, perhaps
unreasonable and perhaps not, is that DMARC was developed by a
collection of organizations who have a shared vision of how
email should work, what is important, and what isn't.  Yahoo is
a supporter/participant in that group, as are several people
with sufficient IETF history and leadership roles to be
knowledgeable about how to facilitate getting a document through
the system.  

I think that raises some issues for the IETF and RFC Editor
about how specifications developed entirely in other bodies --
traditionally, a category known as "specifications developed
elsewhere and republished for the convenience of the Internet
community" -- should be handled.   While it no longer applies in
the DMARC case, there are also some issues associated with
moving stable specifications developed elsewhere through the
IETF Standards Track (whether one calls that "fast track",
"rubber stamp", or something more complementary).   Pete has
mentioned that the IETF is looking at some of the issues
involved; I hope the ISE, and RFC Editor Function more
generally, are too.

As far as the mailman hack is concerned, I think there are two
different relevant audiences/ affected communities:

(i) Receivers who happen to have addresses associated with DMARC
supporters, such as Yahoo, that have adopted a
highly-restrictive policy.  Forcing them into Digest mode, and
warning them that, if they turn it off, they are unlikely to
receive any more list mail and will likely be dropped from the
list seems to be to be appropriate.  It was with that audience
in mind that I claimed that Jeffrey's action was elegant.  I
still think so, YMMD.

(ii) Senders who have chosen to send messages from mail
providers who have adopted restrictive, DMARC-based, policies.
>From my point of view, those providers have made a decision that
they aren't interested in having their mail users post messages
to mailing lists.  If a mail providers wants to effectively
restrict the types of mail their users can send, I think we have
to defend their right to do that.  It is also reasonable to hope
that users who think those services are useful will go elsewhere
and for mailing list managers to protect themselves by denying
posting privileges to such users or remove them from lists.   I
think it would be a great deal more ethical and professional if
those providers took responsibility for that decision with an
explicit announcement to their users, but that is really not an
IETF problem.  

As to your "DMARC-safe mode", I'm inclined to assume that Yahoo
knew exactly what would happen if they made this move.  To
believe otherwise raises significant questions about the quality
of development and review of the DMARC spec and hence whether
the IETF or ISE should publish it in any form, at least in the
absence of a rebuttal or public review and commentary.  The
belief that it was intentional is also reinforced by the
observation that this problem has now been known for quite a
while (in Internet time) and Yahoo has not chosen to modify
their preferences to some other option.  Given that, I think we
should be very cautious about recommending a technique to
subvert their intentions: such actions have too much history of
leading to counter-actions that have even worse effects.

    best,
      john

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Apr 2014 02:02:22 -0700

> leading to counter-actions that have even worse effects.

Dear John,

Well put.

May I say the TPA remedy is under the control of sending domains without impacting mailing list operation, assuming third-party SPF or DKIM or whatever verification benefits from a domain specific authorization.

Employing SRS or vouching like schemes removes control from senders since neither DKIM nor SPF capture intended recipients.  As such, this may have trouble gaining cooperation or retaining delivery integrity with tokens and return-paths arranged like an unmanageable collection of Matryoshka dolls.  TPA can be quickly implemented once a sender expresses a desire to have all needed exceptions under their control.

Regards,
Douglas Otis

---

From: [email-masked]
Date: Mon, 21 Apr 2014 18:13:13 -0700 (PDT)

> > DMARC-safe mode (per subscriber) that optionally rewrites the

As others have pointed out, the only way digest mode solves the problem at hand
is if you force it on every message *from* a domain with a p=reject
policy regardless of recipient.

> involved; I hope the ISE, and RFC Editor Function more

Good point.

> in mind that I claimed that Jeffrey's action was elegant.  I

It's not receivers who have implemented restrictive policies, it's any
receiver who implements DMARC and follows its recommendations for
other domains that implement such policies.

Good luck on determining who those are. As such, enabling conventional
digest mode for some subset of recipients doesn't solve anything.

> to defend their right to do that.

That really depends on whether or not they make that policy clear to people
signing up for their service. Has Yahoo done this?

> It is also reasonable to hope
> posting privileges to such users or remove them from lists.

That's assuming they understand what's causing the issue and have the technical
acumen to make an account switch.

> I think it would be a great deal more ethical and professional if

It becomes one when they can point to an IETF document and say, "Nothing in
here comes right now and says what we're doing is wrong."

> knew exactly what would happen if they made this move.

I'm not. There are far too many examples of organizations engaging in
groupthink and proceeeding down what turns out to be a distasterous path that
winds up costing them major $$$. (Watch "Waterworld" some time.)

Mind you, I'm not saying that this is what has happened at Yahoo. Rather, I'm
saying that absent convincing evidence to the contrary - and the one PR
statement I'm familiar with doesn't even come close to meeting that burden - we
should not make such assumptions.

I also note that other domains that operate in what I'll call "mixed use" (that
is, they're used to send out both personal and business transactional mail,
each of which call for a different DMARC profile) have addressed this issue
through the use of subdomains. For example, Paypal seems to use paypal.com
(with a p=reject DMARC record) for business transaction messages and
e.paypal.com (DKIM but no DMARC record) for everything else. ("e" for email?)

Of course implementing such a scheme on top of existing mixed use allocations
is unpalatable, to say the least. (Unless you were to begin preparing back when
the issues with mixed use domains became clear.) Or it may be that e.yahoo.com
is too close to yahoo.com (but yahoo.e.com presumably is not). Whatever. My
point is that there other alternatives to a blanket p=reject policy choice.

> To believe otherwise raises significant questions about the quality
> absence of a rebuttal or public review and commentary.

I'm afraid I interpret several comments made on this list as asking - and some
answering - those questions already.

But the real question is how do we proceed. If publication of DMARC proceeds
as-is I think a "DMARC Considered Harmful" document is the least unpalatable
outcome. Beyond that things get very ugly indeed.

> The belief that it was intentional is also reinforced by the

Sorry, I'm afraid I disagree. In fact I think it's exactly the opposite.
At a minimum we need to:

(0) Document that the choice of a p=reject is inapproriate for anything
    but a domain devoted to business transaction email and fully describe the
    consequences of using such a policy on other sorts of domains.
(1) Document alternatives to labeling your mixed mode domain with p=reject.
(2) Describe the various mitigation strategies - and their consequences - for
    agents dealing with poor DMARC policy choices, including but not limited to
    advice to MLMs.

And let's keep in mind that this is far more than a simple game of tit-for-tat.
For one thing, DMARC is utterly dependent not only on the willingness of
senders to set up policies, but also on receivers to enforce those policies.
That alone places huge constraints on what is possible.

And for another, by abdicating our responsibilities to do (2), we not only lose
the opportunity to help MLMs choose the best option for their situation, we
also lose the opporunity to explain the consequences of poor choices on their
part. 

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Apr 2014 20:40:59 -0700

>      agents dealing with poor DMARC policy choices, including but not limited to

There already is a first-round internet-draft formulated to be a BCP 
that could be a reasonable home for including such statements:

      http://tools.ietf.org/html/draft-crocker-dmarc-bcp-03

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Apr 2014 13:33:28 +0300

> policy regardless of recipient.

That’s one way to deal with it. The MLM software could identify such messages, and send them to the list recipients Looking like a forwarded message:

From: ietf <[email-masked]>
To: [email-masked]
CC: Joe Blow <[email-masked]>
Subject Re: DMARC and yahoo

Joe Blow <[email-masked]> sent a message from a domain with a p=reject policy. To learn more about this issue, go to https://www.ietf.org/mailman/dmarc-issue

Begin forwarded message: 

> From: Joe Blow <[email-masked]>
> Sent: Tuesday, April 22, 2014 12:30 PM
> To: [email-masked]
> Subject: Re: DMARC and yahoo
>
> I think you guys are making too much of this whole DMARC issue with Yahoo.

---

From: [email-masked]
Date: Tue, 22 Apr 2014 07:03:44 -0700 (PDT)

>       http://tools.ietf.org/html/draft-crocker-dmarc-bcp-03

Yes, that's the obvious place to put this material, rather than putting it
in the base specification. But then the base specification has to reference
this in a normative fashion.

Of course "formulated to be a BCP" doesn't imply actual publication as a BCP,
but even so there would be something a bit odd about having DMARC base as 
independent publication and the DMARC BCP as IETF work.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Apr 2014 08:04:45 -0700

> this in a normative fashion.

While it's plausible and reasonable that a technical specification could 
contain usage guidance like this, it's not at all required.

I believe it for more often that "implications" are typically put into 
BCP-like documents.

For example:

    DomainKeys Identified Mail (DKIM) and Mailing Lists
    https://tools.ietf.org/html/rfc6377

As for doing a BCP on a document that isn't an IETF consensus document, 
we do versions of that periodically, for work developed outside that is 
used by, or affects, IETF-based specs.

d/