Re: [ietf-822] A permission to re-sign header

Theodore Ts'o <tytso@mit.edu> Sat, 19 April 2014 15:52 UTC

Return-Path: <tytso@thunk.org>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856A41A001E for <ietf-822@ietfa.amsl.com>; Sat, 19 Apr 2014 08:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level:
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] 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 WzKd5IVGog83 for <ietf-822@ietfa.amsl.com>; Sat, 19 Apr 2014 08:52:46 -0700 (PDT)
Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8721A0012 for <ietf-822@ietf.org>; Sat, 19 Apr 2014 08:52:46 -0700 (PDT)
Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from <tytso@thunk.org>) id 1WbXZJ-00048q-Nt; Sat, 19 Apr 2014 15:52:41 +0000
Received: by closure.thunk.org (Postfix, from userid 15806) id 239185804CE; Sat, 19 Apr 2014 11:52:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=ef5046eb; t=1397922761; bh=+OKFnLi96oQEML/3gAD65WGTjWejfQW8N1x860yPdeI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SWPmW+2KJNFwTN/kXoOSLoNTjLZgqdP0iA+MQlRB4YesBxBEaKd/ODQFVXtfDLPVe E2SSbMolCWhHhBPzuT+aYv5oTRK2Hw9zjSAUWx0hYIXM7PknfG3doptPvc81S4GGFK RfpO1YHUQbh7xktz3f+WzXGyerMOcKY6X/0Alejk=
Date: Sat, 19 Apr 2014 11:52:41 -0400
From: Theodore Ts'o <tytso@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <20140419155241.GD31552@thunk.org>
References: <20140418021925.2979.qmail@joyce.lan> <53516FA7.3020507@qti.qualcomm.com> <alpine.BSF.2.00.1404181500430.5575@joyce.lan> <6411.1397912723@sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6411.1397912723@sandelman.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/SGRWcNeHoX1i-xJzl9zTXjwW3BQ
Cc: ietf-822@ietf.org
Subject: Re: [ietf-822] A permission to re-sign header
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Apr 2014 15:52:47 -0000

On Sat, Apr 19, 2014 at 09:05:23AM -0400, Michael Richardson wrote:
> 
> Yes, in particular, it's quite likely both DKIM and S/MIME signatures will
> not survive some things the mailing list might want to do, including:
> 
> 1) removing html parts or other attachments
> 2) formatting html part to text/plain
> 3) formatting text/plain; format=outlook into proper format=flowed
> 

We may need to consider whether this is something that we have to give
up.  I'm not sure how important it is to allow mailing lists to remove
html parts, etc.  If mailing lists need to simply reject messages that
have html parts, there are mailing lists that do that already, just as
their are mailing lists that reject messages that dont' meet other
administrative prohibition --- such as the e-mail being too large, for
example.

There are mailing lists that want to "fix" broken messages, yes, but
if we need to provide end-to-end assurance that the message really
came from the originator, disallowing this behavior so that things
like S/MIME and PGP signatures don't get broken might be an
engineering tradeoff that we might have to make.

Cheers,

					- Ted