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@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.