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

Michael Schmeing <schmeing@fgan.de> Wed, 14 June 2006 12:12 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUF0-0006sT-RZ; Wed, 14 Jun 2006 08:12:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUEz-0006pX-Tr for ieprep@ietf.org; Wed, 14 Jun 2006 08:12:57 -0400
Received: from mailguard.fgan.de ([128.7.3.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUEy-0003SW-G1 for ieprep@ietf.org; Wed, 14 Jun 2006 08:12:57 -0400
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1FqUEx-0002j6-9K; Wed, 14 Jun 2006 14:12:55 +0200
Received: from nordhorn.fkie.fgan.de ([128.7.5.132]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1FqUEw-0001RE-00; Wed, 14 Jun 2006 14:12:54 +0200
Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Wed, 14 Jun 2006 14:12:54 +0200
Date: Wed, 14 Jun 2006 14:12:54 +0200
From: Michael Schmeing <schmeing@fgan.de>
To: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities
Message-ID: <20060614121253.GB2555@nordhorn.fkie.fgan.de>
References: <20060612130135.GD9821@nordhorn.fkie.fgan.de> <AFFB0D31-7CA6-4CD3-8094-7BBD234F755F@g11.org.uk> <20060614045308.GA2412@nordhorn.fkie.fgan.de> <E13FD0A8-0DC4-49CF-834D-604214983A7C@g11.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E13FD0A8-0DC4-49CF-834D-604214983A7C@g11.org.uk>
Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN)
User-Agent: Mutt/1.5.11+cvs20060403
X-Virus-Scanned: yes (FGAN VirusScan III)
X-Scan-Signature: e39b0b635d2099d1d28d84c0f3b7851d
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org

On Wed, Jun 14, 2006 at 07:12:08AM -0400, ken carlberg wrote:
> [...]
> >>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.
> 
>    [...]
> 
> 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.

To me, this appears rather to be a problem of different definitions of
the term content than a misinterpretation. I meant content as in
"message content" that is defined in Sec. 2.3.9 of RFC 2821 (SMTP) as
  "the material transmitted after the DATA command is accepted and
   before the end of data indication is transmitted.  Message content
   includes message headers and the ... message body."
In this definition the email header is part of the content. As such it
may be secured using S/MIME but still is outside the (current) scope
of the draft.

S/MIME obviously has a different definition of the term "content" that
only includes (parts of?) what is called "message body" but excludes
at least some header fields (probably those defined in RFCs
2821/2822).




Greetings,
Michael
-- 
****************************************************
| Michael Schmeing       E-Mail:  schmeing@fgan.de |
| FGAN/FKIE              Tel: (+49) 228/9435 593   |
| Neuenahrer Strasse 20  Fax: (+49) 228/9435 685   |
| D-53343 Wachtberg, Germany                       |
****************************************************

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep