That would make a mess of time stamps, especially on an international list.
Or any list spanning multiple timezones.
Maybe it would be better to override the sending time stamp only when it's, say, 2 days or more away from the Mailman server time?
To really do it properly, you'd have to parse the date/time stamps on every hop that the message passed through, converting them all back to a common baseline (presumably something like UTC). When the "Date:" header is out-of-whack in comparison to the date/time stamps in the "Received:" headers, then it could be corrected (re-converted to the appropriate timezone, of course).
But what would you do if some of the "Received:" headers agreed reasonably closely with the "Date:" header, and some didn't? How would you tell what might have been forged versus what might have been caused by a server being down for a few days, or whatever?
Fundamentally, I do not think that this is a solvable problem, or that much effort should be expended in attempting to solve it.
-- Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
This message was sent to: [EMAIL PROTECTED] Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
