[Mailman-Developers] Dates again

[Steven Kuck]

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.