I have had that in mind. A simple heuristic might be year > this_year + 1, so we'll allow next year but not more than that. If we're just trying to catch mis-parses from GMime, this should do the trick.
If we actually want to sanitize the dates, that's another story. Aaron On Tue, Jan 2, 2007, Jesse Norell <[EMAIL PROTECTED]> said: > Doesn't this mean that if either the sending or receiving mail server's > time were a little off, you could have valid mail changed to be a year > earlier? Eg. sender's server is a couple hours ahead of the receiver, > and someone sends an email at 11:00 on Dec. 31 (receiver's time) .. it > would change the date to be one year earlier (and presumably show up > incorrectly in mailbox listings)? > > > On Sun, 2006-12-31 at 22:32 +0100, [EMAIL PROTECTED] wrote: >> Proposed solution per mailing list discussion is to check if GMime >> thinks >> that the year is > the current year, and replace with the current year >> if >> that's the case. > -- > Jesse Norell - [EMAIL PROTECTED] > Kentec Communications, Inc. > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > -- _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
