Tokio Kikuchi wrote:
Well, the logic may be unclear but calculate_attachment_dir() tries again to guess the real date of message arrival because it may be called from bin/arch. I think the code should be cleaned up but since we are now dealing with the email parsedate bug and it should be safe to limit our patch to this purpose.
I ran into a problem with this while testing something else. I posted a message using bin/inject and also had scrub_nondigest true. The message got shunted in Scrubber's calculate_attachments_dir because parts = msg.get_unixfrom().split() threw an exception because msg.get_unixfrom() was None.
Anyway, I wasn't concerned about that per se, but rather about how the process had gotten that far. It turns out that email.Utils.parsedate() returns a 9-tuple with tm_yday = 0 which is not acceptable to time.strftime() in Python 2.4, but it is OK for time.mktime().
When safe_strftime() returns None, we get to datestr = msgdata.get('X-List-Received-Date') if datestr: datedir = safe_strftime(fmt, datestr)
This is a problem too - first, X-List-Received-Date is a message header, not message metadata and second it is a formatted date which is not the right argument for strftime so safe_strftime() returns None again and we fall back to unixfrom.
Perhaps the workaround patch for parsedate should be something like
+def parsedate(data):
- if not data:
return None- t = _parsedate(data) ++ if not t[7]: ++ t = t[:7] + (1,) +t[8:]
- try:
time.mktime(t)- except OverflowError:
return None- return t
and similarly for parsedate_tz
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan