[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--