Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-02.txt

Alessandro Vesely <vesely@tana.it> Sat, 19 May 2012 09:55 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 3F31521F8692 for <apps-discuss@ietfa.amsl.com>; Sat, 19 May 2012 02:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level:
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[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 1LSfha+vnmTI for <apps-discuss@ietfa.amsl.com>; Sat, 19 May 2012 02:55:51 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F34C321F867A for <apps-discuss@ietf.org>; Sat, 19 May 2012 02:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1337421339; bh=f/4CJ7Z0YxK8gXRO508r21/og4ONxRK3FbofSDnOMBY=; l=1226; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=RQo2juC2bw5QTr26pm4hl+03Zz7683lcTexCpyXPKf3SAzKVUt8BiTrl3e7OdTKBb MZ7++qm30wS6CELSJHug7atIqSkX+rEjNG/nBqg8fPm8pKtzzTiCNlRos68YFEWCNo BA2VxA1JO5T52OJPtrXHxXrNavSEHLHx3zAZtNUc=
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; Sat, 19 May 2012 11:55:39 +0200 id 00000000005DC044.000000004FB76E1B.00002105
Message-ID: <4FB76E1B.2010902@tana.it>
Date: Sat, 19 May 2012 11:55:39 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20120519084443.27640.95847.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039281271F8@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E0039281271F8@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-02.txt
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: Sat, 19 May 2012 09:55:52 -0000

On Sat 19/May/2012 11:28:41 +0200 Murray S. Kucherawy wrote:
> 
> I've also changed the document's state to Informational from BCP,
> now that I understand how we use the latter term here.

Just to make sure, I grasp that "here" BCP refers to issues internal
to the standardization process, as RFC 2026 auto-referentially states.
 Its Section 5, however, seems to mention that as the third of three
possibilities:

   A BCP document [...] is a vehicle by which the IETF community can
   define and ratify the community's best current thinking on a
   statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

> 
> Comments welcome.

One surprising statement is
				
   The following use of unbalanced quotation marks:

      To: "Joe <joe@example.com>

   should be interpreted as:

      To: "Joe <joe@example.com>"@example.net
				
   where "example.net" is the domain name or host name of the
   handling agent making the interpretation.

If that were a "From:" field, wouldn't it represent an attack path
against example.com's ADSP settings?  IMHO, a DKIM verifier should
make an exception to that rule, and tag the message as discardable, if
that's the case.