[Mailman-Developers] Dates again

Brad Knowles brad at stop.mail-abuse.org
Sun Nov 21 01:53:50 CET 2004


At 6:22 AM -0500 2004-11-20, Steven Kuck wrote:

>  I feel as though I've suggested making burgers from a sacred cow...  I
>  would like to figure out why it is sacred, so pardon my sacrilegious
>  question: why does it matter?  Please, no flames...

	Riiiiiiiiiiiiiiiiiiiiiiiight.

	You feel free to include all your own inflamatory comments before 
the question, and then insist that this can't lead to a flame war. 
This is not a good start.

>                                                       Can you point me to
>  the definitive text for mail header definitions?  RFC 733 only defines
>  the format - it doesn't say they are any more inviolate than the
>  "Subject" line.

	I believe that the current RFC on this matter is 2822, see 
<http://www.faqs.org/rfcs/rfc2822.html>.  The last paragraph of 
Section 3.6 says:

|   The only required header fields are the origination date field and
|   the originator address field(s).  All other header fields are
|   syntactically optional.  More information is contained in the table
|   following this definition.

	This implies to me that the "Date:" header is one of the two most 
important headers on the entire message.  Keep that in mind.  Section 
3.6.1 says:

|3.6.1. The origination date field
|
|   The origination date field consists of the field name "Date" followed
|   by a date-time specification.
|
|orig-date       =       "Date:" date-time CRLF
|
|   The origination date specifies the date and time at which the creator
|   of the message indicated that the message was complete and ready to
|   enter the mail delivery system.  For instance, this might be the time
|   that a user pushes the "send" or "submit" button in an application
|   program.  In any case, it is specifically not intended to convey the
|   time that the message is actually transported, but rather the time at
|   which the human or other creator of the message has put the message
|   into its final form, ready for transport.  (For example, a portable
|   computer user who is not connected to a network might queue a message
|   for delivery.  The origination date is intended to contain the date
|   and time that the user queued the message, not the time when the user
|   connected to the network to send the message.)

	There's nothing here that says that an MTA should, or can, 
correct a "Date:" header that it believes to be incorrect.  There's 
nothing here that says an application can or should correct a "Date:" 
header that it believes to be incorrect.

	You should also read section 3.6.6, and note that it is not 
applicable since "Resent-" fields are for when a user has 
re-introduced a message into the transport system, and this is not 
what we are doing.  Moreover, the "Resent-" fields are purely 
informational, and do not over-ride the original fields in the 
message in any way.


	For my part, all this means that the "Date:" header is even more 
inviolable than the "Reply-to:" header, which is a very old flamewar. 
See 
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.048.htp>.



	As for the rest of your message, I consider it to be sufficiently 
inflamatory that I will not attempt to respond.  You seem to have a 
clear agenda here, and there is nothing that will deter you from this 
path.  If you wish to modify your system to function the way you 
want, there's not really much that any of us can do to try to change 
your mind.

	However, if you do actually want to try to benefit the rest of 
the Mailman community, or at least to avoid having to keep re-porting 
your change to every new version of Mailman, you're going to have to 
make some concessions to the patch you are proposing.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.


More information about the Mailman-Developers mailing list