[Mailman-Developers] Patch for HyperArch

[Mark Sapiro]

On 03/10/2016 10:10 AM, Mark Sapiro wrote:
> 
> For the actual "fix", my inclination is to modify the _set_date method
> in pipermail.py (this is called from Hyperarch.py as
> self.__super_set_date(message) just before it does self.fromdate =
> time.ctime(int(self.date)).
> 
> I would have this check the date and if it's not within say 50 years of
> now, replace the date with something reasonable. My question at this
> point is what's that something reasonable. I think it comes down to a
> choice between the From_ date if that's reasonable or the current date,
> but I don't know which is better.


I have reported this bug and fixed it. The bug is
<https://bugs.launchpad.net/mailman/+bug/1555798> and the fix is
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1633>

The fix looks at message timestamps in the following order:

The Date: header if any
An X-List-Received-Date header if any
The last Received: header if any
The Unix From_ line

The first parseable date which is in the current epoch (>= 1970) and not
more than mm_cfg.ARCHIVER_ALLOWABLE_SANE_DATE_SKEW (default 15 days) in
the future is accepted. If none of those produce an acceptable date, the
current time is used.

This differs from past behavior by the addition of range checks on the
date and the addition of Received: and Unix From_ date checks.

The Received: header check is important. For an "imported" mbox, the
From_ separators may reflect when the mbox was exported from it's source
rather than the message date. If the messages have Received: headers,
the later ones at least tend to have good dates.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan