Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities

ken carlberg <> Wed, 14 June 2006 11:12 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FqTIF-0001D0-Ta; Wed, 14 Jun 2006 07:12:15 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FqTIE-0001Cu-FF for; Wed, 14 Jun 2006 07:12:14 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1FqTID-0007R5-63 for; Wed, 14 Jun 2006 07:12:14 -0400
Received: from [] (helo=[]) by with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from <>) id 1FqTIE-0002Eb-RJ; Wed, 14 Jun 2006 12:12:15 +0100
In-Reply-To: <>
References: <> <> <>
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: ken carlberg <>
Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities
Date: Wed, 14 Jun 2006 07:12:08 -0400
To: Michael Schmeing <>
X-Mailer: Apple Mail (2.750)
X-Spam-Score: -4.4 (----)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> this is just a quick answer to a couple of points I can respond to off
> hand. I am going to give a more complete answer next week (I am out of
> office starting tommorow until Monday including).

hmmmm, planning to take some time off to see the next German football  
match? :-)
(just kidding)

>> [...]
>> Outside of that, it would seem desirable for your draft to at least
>> advocate some measures of security like S/MIME for header protection
>> (rfc-3851), and possibly the use of AUTH.
> S/MIME is strictly for the content of the email. This area has been
> left out of the draft because of reasons stemming from the research
> project I work on. In the general case it is probably a good idea to
> at least consider this area. As for AUTH, you are completedly right.

Section 3.1 of rfc-3851 has the following text...

    In order to protect outer, non-content related message headers (for
    instance, the "Subject", "To", "From" and "CC" fields), the sending
    client MAY wrap a full MIME message in a message/rfc822 wrapper in
    order to apply S/MIME security services to these headers.  It is up
    to the receiving client to decide how to present these "inner"
    headers along with the unprotected "outer" headers.

    When an S/MIME message is received, if the top-level protected MIME
    entity has a Content-Type of message/rfc822, it can be assumed that
    the intent was to provide header protection.  This entity SHOULD be
    presented as the top-level message, taking into account header
    merging issues as previously discussed.

I was under the impression that the above left the door open for S/ 
MIME to protect static parts of the SMTP header.  But admittedly, I'm  
not deeply familiar with the draft, so my apologies if I've  
misinterpreted things.


Ieprep mailing list