Bug 3893 - mass-check -n makes time= result a message count
Summary: mass-check -n makes time= result a message count
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Masses (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P3 normal
Target Milestone: 3.1.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-11 08:01 UTC by Theo Van Dinter
Modified: 2004-10-11 11:34 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Theo Van Dinter 2004-10-11 08:01:10 UTC 
While working with Henry on a few things, we found that my mass-check results had invalid time= 
values:

. -2 /home/felicity/SA/corpus/ham/goodmsgs.68463 
ALL_TRUSTED,NO_REAL_NAME,__HAS_MSGID,__HAS_SUBJECT,__MSGID_OK
_DIGITS,__MSGID_OK_HOST,__SANE_MSGID,__UNUSABLE_MSGID time=11,scantime=0
.  0 /home/felicity/SA/corpus/ham/ebay.0 
NO_REAL_NAME,__CD,__CT,__CTE,__CT_TEXT_PLAIN,__HAS_MSGID,__HAS_SUBJEC
T,__MIME_VERSION,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__SANE_MSGID,__UNUSABLE_MSGID 
time=12,scantime=0
.  0 /home/felicity/SA/corpus/ham/ebay.4237 
NO_REAL_NAME,__CD,__CT,__CTE,__CT_TEXT_PLAIN,__HAS_MSGID,__HAS_SUB
JECT,__MIME_VERSION,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__SANE_MSGID,__UNUSABLE_MSGID 
time=13,scantime=0

turns out that the time= value is simply a message count if the -n option is used.
Comment 1 Theo Van Dinter 2004-10-11 08:31:11 UTC 
this is holding up some results I'm getting for henry, so I may as well fix the issue. ;)

btw: it's not trivial.  the message number is used because the first part of mass-check doesn't need to 
read in the message to get the receive date, but then later on the date isn't updated even when it's read 
in the message.  so I'm trying to figure out how to pass information back up the chain.
Comment 2 Theo Van Dinter 2004-10-11 19:34:19 UTC 
ok, this is fixed now, I believe.  r54644

basically, have run_message be the master in charge of determining class, format, location, and date.  
if when we're taking a message out from the input, the receive date is set to -1 (set at scan time), we 
take the headers and determine receive_date, overriding the -1, and pass it back up the call chain.  at 
the end, the wanted function gets the right data, as does the result function, and all the changes are 
internal. :)

I'd appreciate more heavy testing, but since the public API doesn't change it should, in theory work. ;)