Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail)
Alessandro Vesely <vesely@tana.it> Tue, 06 March 2012 15:12 UTC
Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB321F889A for <apps-discuss@ietfa.amsl.com>; Tue, 6 Mar 2012 07:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level:
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S0M0OuPmhW4 for <apps-discuss@ietfa.amsl.com>; Tue, 6 Mar 2012 07:12:37 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73021F87B3 for <apps-discuss@ietf.org>; Tue, 6 Mar 2012 07:12:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331046755; bh=AACCNc0fQNBJx5ioK4QGIA2qpqKCwHN2Ucyj+NsmaH8=; l=1570; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=boaLbqp99Ign7BT1GhHOkBGqRpfsV+5ARSW3tsdqM19MxgK6JxPwN5TlTnBPy8nzR z9lxGr9y3BXBEWq1/xrIARv6TIgmj3WrM6cc8A7pEoX4evgCLpK+SkIsu/Kassmxi9 0XXeg8jPfFggIosrnALAdrWir/bOugJc67lHzY6M=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 06 Mar 2012 16:12:35 +0100 id 00000000005DC045.000000004F562963.000064AB
Message-ID: <4F562963.3000501@tana.it>
Date: Tue, 06 Mar 2012 16:12:35 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <4F549914.2020907@tana.it> <01OCQYO1P7T400ZUIL@mauve.mrochek.com> <4F5504A4.6010902@tana.it> <01OCRXKYBLNA00ZUIL@mauve.mrochek.com>
In-Reply-To: <01OCRXKYBLNA00ZUIL@mauve.mrochek.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 15:12:38 -0000
On 06/Mar/12 09:04, Ned Freed wrote: > >> Hm... MIME doesn't seem to say that either is better than the >> other. Based on what you write below, I'd derive that token is >> better than quoted-string, provided that quotes are actually >> superfluous. Hence, the I-D could state that that's the >> canonical syntax, implying that DKIM signers (and verifiers) may >> get smoother if they convert that way before playing their >> magic. > > I'm unclear as to the relevance. If you're transforming MIME > content in some way - and if you're not why are you bothering to > mess around with the headers - the content will be altered and any > DKIM signature is going to be invalidated no matter what you do to > the quotes. Not necessarily. The message you replied to was sent to apps-discuss with Content-Type: text/plain; charset=us-ascii, but I received it from mail.ietf.org with Content-Type: text/plain; charset="us-ascii". Thus, the message was rewritten, and its signature would have been broken if the Content-Type field had been signed (which should be the behavior of choice, according to RFCs 6376-6377.) As for the relevance, I admit it's a statistically irrelevant corner case, which looks more like a DKIM shortcoming than a MIME fault. > I don't see a problem with saying that, but a document that says > that and that alone doesn't seem worth it to me. I'm also dubious > that anything would change significantly because of making such a > recommendation. Yet, the less MIME rewriting, the more DKIM deployment is possible.
- [apps-discuss] Malformed mail guidance document (… Murray S. Kucherawy
- Re: [apps-discuss] Malformed mail guidance docume… Scott Kitterman
- Re: [apps-discuss] Malformed mail guidance docume… Alessandro Vesely
- Re: [apps-discuss] Malformed mail guidance docume… Ned Freed
- Re: [apps-discuss] Malformed mail guidance docume… Alessandro Vesely
- Re: [apps-discuss] Malformed mail guidance docume… Ned Freed
- Re: [apps-discuss] Malformed mail guidance docume… Alessandro Vesely
- Re: [apps-discuss] Malformed mail guidance docume… Ned Freed
- Re: [apps-discuss] Malformed mail guidance docume… Murray S. Kucherawy
- Re: [apps-discuss] Malformed mail guidance docume… Ned Freed