http://bugzilla.spamassassin.org/show_bug.cgi?id=2372
------- Additional Comments From [EMAIL PROTECTED] 2004-05-03 21:57 -------
Good news - looks like we're all go with the mbx patch. I've tested what I've
got so far and all is looking good. A couple of questions before I submit the
final patch...
1. The mbx message separator's a little more complex than the mbox one. For
example:
/([\s|\d]\d-[a-zA-Z]{3}-\d{4}\s\d{2}:\d{2}:\d{2}.*),(\d+);([\da-f]{12})-(\w{8})/o
compare with
/^From /
found elsewhere for mbox mailboxes.
My first question is, what module's best suited to store the above constant
given I reference in two different places (ArchiveIterator.pm and Message.pm)?
2. My second question's really an RFC822/date related one. In two places in
Bayes.pm, receive_date (a function also found in ArchiveIterator.pm) gets called
with all mbox and/or mbx headers. That is, including the mailbox separator
(which contains a date string). The problem here is, the date string in the
mbox separator is rfc822 compliant, the date string in the mbx separator is not.
For example:
18-Feb-2004 11:50:57 +1300,3309;000000000009-00020d9b
There are two different but equally valid ways of solve this (so far as I can
see).
a) Modify Mail::SpamAssassin::Util::parse_rfc822_date so that it can parse the
mbx date string. In that case, a name change is probably required.
b) At the point that I read-in the mbx separator, I store it internally in SA's
{'mbx_sep'} in mbox format, as a sort of de facto portability standard.
Personally I prefer a) although feedback would be good on this one.
Cheers,
John.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
