Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03

Alessandro Vesely <> Sat, 06 March 2010 11:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F1B03A8F53 for <>; Sat, 6 Mar 2010 03:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.661
X-Spam-Status: No, score=-4.661 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a0UMT1FLcZnX for <>; Sat, 6 Mar 2010 03:36:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0A5873A8632 for <>; Sat, 6 Mar 2010 03:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=test; t=1267875359; bh=xtPTcqcJ3SR6m8EyT0GKaFuaII7BYnXQHcn3cfA7rzk=; l=2029; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Ht8dNXSoru7dEMLihZSPMb+I56SRr0etcgEaWcR5ynMX2TmAtf9RdCnKZ9xl2qqf/ Jp2wZVMv3oZ+F02UqUSzkQ581iZY7eCIsicoBLdCB8ods+TffPaQ593wFIfmMxSaFI C0D4nFyQ1oNw4F/KwIrS0dPL2V3Np1OFDupn4Ouc=
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by with ESMTPSA; Sat, 06 Mar 2010 12:35:59 +0100 id 00000000005DC033.000000004B923E1F.00005043
Message-ID: <>
Date: Sat, 06 Mar 2010 12:35:58 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Mar 2010 11:36:01 -0000

Hi SM,

>> RFC 4871 is of 2007 and reports an issue with it. Section 5.3 practically says that 8bit SHOULD NOT be used.
> Section 5.3 of RFC 4871 sounds more like a deployment consideration instead of a security consideration.

Yes, it is the deployment of a security add-on, though.

> The question from Stephen Kent [1] in response to my comment mentions that "binary attachments that are ideal for delivering malware are supported irrespective of the use of" the 8BITMIME extension. Dave Crocker requested input from the WG on the secdir review [2]. His message gives a broader view of the matter (i.e. whether the change is within scope for the YAM WG).

I don't know what "actual substance" outside of yam's scope Dave has 
been talking about.

Mail is often overlooked during generic talks about Internet security, 
where they primarily consider the web and the DNS. My feeling is that 
the WG should attempt to correct such general stance, but not at the 
cost of "leading to madness", in John's words.

> My position is that an issue was brought up during the Secdir review and I need an answer for the Responsible Area Director and YAM WG Chairs.

For the specific 8BITMIME case, I also agree with what Ned has said. 
It would sound grandiloquent to say that 8bit is dangerous because it 
is one of the many ways to break DKIM. I don't think it is a real concern.

> I wrote some notes about hostile content ( temporary link ). It is not meant to be used as input for YAM WG work.

Interesting effort.

Hostile content is not the only risk. Disclosing sensible information 
is another pitfall. For example, consider attaching the "wrong" file 
and/or sending to the "wrong" recipient. Similar leakage can also 
occur with abuse reporting buttons --that will hopefully break loose 
from web based MUAs-- as users may inadvertently "throw" messages 
containing sensible data, into potentially unfriendly FBLs.