[Fwd: MSAs (RFC 2476), RFC 2822, and the Date field]

Bruce Lilly <[email protected]> Sat, 21 Aug 2004 15:00:52 -0400
Newsgroups gmane.ietf.submit,gmane.ietf.rfc822
Organization Bruce Lilly
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------050909080108070104090807
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oops, forgot the list copies...

--------------050909080108070104090807
Content-Type: message/rfc822;
 name*0*=ISO-8859-1'en-us'MSAs%20%28RFC%202476%29%2C%20RFC%202822%2C%20and
 name*1*=%20the%20Date%20field
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0*=ISO-8859-1'en-us'MSAs%20%28RFC%202476%29%2C%20RFC%202822%2C%20
 filename*1*=and%20the%20Date%20field

Message-ID: <[email protected]>
Date: Thu, 19 Aug 2004 10:21:17 -0400
From: Bruce Lilly <[email protected]>
Reply-To:  [email protected]
Organization: Bruce Lilly
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us
MIME-Version: 1.0
To:  [email protected]
CC: Jacob Palme <[email protected]>
Subject: MSAs (RFC 2476), RFC 2822, and the Date field
References: <[email protected]> <[email protected]> <p0611040bbd4902ddb2d8@[192 .168.168.22]> <[email protected]> <p0611040fbd492cde8b38@[192.168.168.22]> <[email protected]>
In-Reply-To: <[email protected]>
X-Enigmail-Version: 0.85.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email protected] wrote:

[quoting Jacob Palme]
>>like for examples is already accepted that the initital MTA
>>may add a "Date" header for a message lacking such a
>>header.
> 
> 
> Actually, it isn't accepted for an MTA to do this. It can be done by an MSA,
> which is a different beast.

Note that RFC 2822 defines the semantics for the Date field as
representing the time of completion of composition of the message,
not the time of entry into the transport stream.  Of course RFC 2476
predates RFC 2822, and RFC 822 and earlier were not as precise
regarding the Date field semantics.  The next revision of RFC 2476
as it progresses along the Standards Track should probably address
that discrepancy.


--------------050909080108070104090807--