Re: DMARC and yahoo

John C Klensin <john-ietf@jck.com> Mon, 21 April 2014 06:50 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC61A010C for <ietf@ietfa.amsl.com>; Sun, 20 Apr 2014 23:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.472
X-Spam-Level:
X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B3T07p9bZ7L for <ietf@ietfa.amsl.com>; Sun, 20 Apr 2014 23:50:05 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 363091A00B1 for <ietf@ietf.org>; Sun, 20 Apr 2014 23:50:05 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Wc833-000JD9-TK; Mon, 21 Apr 2014 02:49:49 -0400
Date: Mon, 21 Apr 2014 02:49:49 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: DMARC and yahoo
Message-ID: <DFC043AEFFD831DBABB4A5D9@[192.168.1.128]>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/w98unFVwFSkEomIBJPxu2SHnxSw
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Theodore Ts'o <tytso@mit.edu>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Apr 2014 06:50:07 -0000

--On Monday, 21 April, 2014 08:26 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> 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