Brad Knowles wrote:
At 3:31 AM -0500 2004-11-20, Steven Kuck wrote:
Since all of these messages are, in fact, being sent by my server I think
it quite reasonable to change the "Date" to reflect the time that it was
processed and changed by the server.
The problem is that you can't tell which "Date:" headers are good and which ones aren't. The message may have been held up in a queue for several days, or the date it was sent could be off by several days. By the time the message gets to you, it is impossible to distinguish between these two events.
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... 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.
True, you can't tell if a message was sent from a misbehaving computer or if it got stuck in the queue of a misbehaving server. Surely, any dates in the future would be fair game for alteration - they can't have been "stuck" there since NEXT week. I'd also be suspect of any dates before 1970. Frankly, I'd be suspect of any date older than a three days (over a weekend).
I still think that the time on the originating computer (assuming the sender isn't inserting false dates) is a matter for trivia, and archival in a "X-Sender-Universal-Disjointed-Time" field. Why do I care if the message was stuck (unless it's my server) or if the user's clock is wrong?
IMO, you should adhere to the principle of minimal munging, and not replace a "Date:" header unless you can pretty conclusively prove that it was set wrong to begin with.
Come now, it's not like I'm adding content to the body of the message! Oh wait, mailman does that too.
I would be violently opposed to any system-wide modification that would arbitrarily replace all "Date:" headers with ones based on the time of reception.
As I said, I can guarantee messages from the future are wrong. Disagree?
Perhaps messages from more than a day (or N days) in the past could be bounced saying:
"Either your system clock is wrong or your message was unreasonably delayed. Either fix your clock, or make sure your message is still current and send it again."
Alternately, the message could be held for approval or date fixing, and you could set that user as "Date Impaired" so that all messages from that individual get fixed - if they're off.
PS I considered sending this message from the year 2080 as I've had to
deal with, but I thought I'd give you a chance to implement this patch first.
We've all had the problem.
At least you recognize it as a "problem." I would be more than happy to work on a reasonable, if not totally infallible "solution." I know as a current solution we tolerate a message archive on this list from 2006. If date > now, replace. Can we at least get that in there? I'll worry about messages from 1989 or earlier on my own.
Steven Kuck - no need for "violent opposition" - I'll behave. _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
