Re: Suggestion: can we test DEMARC deployment with a mailing list?
Dave Crocker <dhc@dcrocker.net> Sat, 03 May 2014 16:23 UTC
Return-Path: <dhc@dcrocker.net>
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 835051A00E6; Sat, 3 May 2014 09:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 V24GWTYTiZjO; Sat, 3 May 2014 09:23:27 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 487F91A0097; Sat, 3 May 2014 09:23:27 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s43GNIGx012895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 3 May 2014 09:23:21 -0700
Message-ID: <536517EE.6050800@dcrocker.net>
Date: Sat, 03 May 2014 09:23:10 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>, IETF <ietf@ietf.org>
Subject: Re: Suggestion: can we test DEMARC deployment with a mailing list?
References: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com>
In-Reply-To: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 03 May 2014 09:23:22 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/KM4yU52K9VcjplgItBDl2x_F6nM
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Sat, 03 May 2014 16:23:28 -0000
On 5/2/2014 1:05 PM, Fred Baker (fred) wrote: > As an example of the case that comes to mind, see attached. It is a > message sent to v6ops@ietf.org yesterday. The sender signed it > using DKIM, the IETF changed the message (added some trailing text) > before forwarding it, the receiver (e.g., Cisco IT) attempted to > validate the DKIM signature - and failed. > > It seems to me that we should not approve a procedure that has that > effect, at least without some guidance for mail relay > administrators. I could imagine two forms of guidance: “obey the > end-to-end principle; don’t change the message the originator > sent”, or “if you change a signed message, first validate the > message you received and discard if that fails, change it, and then > sign it yourself, so that a receiver can see who changed it and > validate the outcome”. Fred, Your comments are consonant with the recurring comments of others, so it's worth repeating several fundamental points about them: 1. The so-called "end to end principle" was actually labeled end to end /arguments/. It is a guidance about a design approach that then needs to be tailored to the specifics of the situation. For example, the definition of 'end' varies according to the scenario. With direct, person-to-person email the mailbox is an end point. For EDI over email, it isn't, since there is a further processing sequence after email delivery. So we need to be rather careful when asserting the 'principle'. In the IETF, we've grown fond of tossing out the label as if its mere statement is useful. However it's actual utility only happens as part of a tailored design discussion. Like a protocol, its utility requires being set into motion. 2. In terms of basic email architecture, a mailing list is an end-point. The author specifies the mailing list explicitly. The mail gets /delivered/ to it. A mailing list is not an MTA that is relaying mail; it is an end-user application that /re-/posts it. So a mailing list is really a value-add mechanism that sits above the basic email service. In architectural terms, this is identical to your choosing to forward this note to someone you think should see it. DKIM is meant for transit protection, starting somewhere near the (original) author and ending somewhere near the mailbox of the specified (initial) recipient. In the case of a mailing list, that mailbox belongs to the mailing list. Should a DKIM signature survive your manual forwarding of a message? While it's certainly acceptable for it to survive, it's not reasonable to expect it. Then why should we expect the re-posting by a mailing list to preserve a DKIM signature? Depending upon the policies of a specific mailing list, there are many very good reasons for the changes that are made to the original message. Some of those happen to break a DKIM signature. 3. The limitations of DMARC have been well understood, including by both Yahoo and AOL. There is never any way for the IETF community to protect against an organization's choosing to apply a protocol in a way that is known to have damaging effects. 4. There is, in fact, a draft BCP about DMARC use that was posted and awaits pursuit, preferably in the IETF.[1] Working on it got stalled by the gyrations of trying to decide how to process the DMARC base specification. Perhaps we should focus our energies into firing up an IETF engine to develop and progress the BCP? d/ [1] Using DMARC, https://datatracker.ietf.org/doc/draft-crocker-dmarc-bcp/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
- Suggestion: can we test DEMARC deployment with a … Fred Baker (fred)
- Re: Suggestion: can we test DEMARC deployment wit… Christopher Morrow
- Re: Suggestion: can we test DEMARC deployment wit… Douglas Otis
- Re: Suggestion: can we test DMARC deployment with… John Levine
- Re: Suggestion: can we test DEMARC deployment wit… Dave Crocker
- Re: Suggestion: can we test DMARC deployment with… Fred Baker (fred)
- Re: Suggestion: can we test DMARC deployment with… John R Levine
- Re: Suggestion: can we test DMARC deployment with… Theodore Ts'o
- Re: Suggestion: can we test DMARC deployment with… Douglas Otis
- Re: Suggestion: can we test DMARC deployment with… John R Levine
- Re: Suggestion: can we test DEMARC deployment wit… Hector Santos
- Re: Suggestion: can we test DMARC deployment with… Theodore Ts'o
- Re: Suggestion: can we test DEMARC deployment wit… Hector Santos
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Miles Fidelman
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Fred Baker (fred)
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Miles Fidelman
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Fred Baker (fred)
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Dave Crocker
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Hector Santos
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Douglas Otis
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Hector Santos
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… ned+ietf
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Hector Santos
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Hector Santos
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… John Levine
- Re: [dmarc-ietf] Suggestion: can we test DEMARC d… Doyle, John