User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: version 1.0.5 (20050711) Hi, I have recently started running statistics on my junklog.html file.. however because it appears to log the date and time on the message rather than the system date and time.. I end up with statistics saying 21 messages were filtered out in the future. I am sure you know this but... Due to the way the spammers work they pre-date the messages to appear at the top of the in-box.. this date is used in junklog.html. Is it possible that in the future the junklog.html file could work on the system date and time that the message was detected rather than the date that the message had? Reproducible: Always Steps to Reproduce: 1. Run Thunderbird.. enable auto junk mail filtering into a junk mail folder 2. Enable logging 3. Wait for a spam message with the wrong date 4. Look in the log and the " at " date is incorrect if the spam contained an incorrect "sent" date.. Actual Results: Incorrect dates in junklog.html Expected Results: Used the system date and time rather than the incorrect date and time from the "spam". Windows XP SP2 - Imap mail server with junk filter moving messages into "Held Mail" folder on the imap server. All works well apart from the logged date.
This would be helpful. Another problem stemming from this is in regard to the "Automatically delete junk messages older than X days from this folder" setting. If I receive junk mail from the future, it will never get deleted from the junk folder until X days after that future date/time. This means I have extra junk mail sitting around which I don't want (sometimes for years!)
Assignee: mscott → nobody
Severity: trivial → enhancement
Component: General → MailNews: Filters
OS: Windows XP → All
Product: Thunderbird → Core
QA Contact: general → filters
Hardware: PC → All
Comment 1 is bug 355113. For *this bug*, the code is here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/base/src/nsSpamSettings.cpp&rev=1.33&root=/cvsroot#601 ... is someone want to make it use received date (bug 166254) instead.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It is probably intentional that the date from message is used in the log entry. It is a means to identify the message if you want to log for it in the Junk folder. But I think each log entry should have a timestamp preceding it to indicate the real time when the message was filtered. Tom, would that work for you?
Amazing.. a reply to a 10 year old bug submission :) Since then I've moved jobs, house and mail client! However; I'm sure an extra field would help others affected by the bug.
Add timestamp at the start of each junk and filter log entry.
Attachment #8629666 - Flags: review?(rkent)
Comment on attachment 8629666 [details] [diff] [review] patch Review of attachment 8629666 [details] [diff] [review]: ----------------------------------------------------------------- Sorry to take so long with this, getting TB 38 stable has us swamped. Looks good with a couple of changes, I don't need to see it again after these fixes. ::: mailnews/base/search/src/nsMsgFilter.cpp @@ +654,5 @@ > buffer += "\n"; > > + // Prepare timestamp > + date = PR_Now(); > + PR_ExplodeTime(date, PR_LocalTimeParameters, &exploded); Since you are getting this locally, and only using it once, just use: PR_ExplodeTime(PR_Now(), PR_LocalTimeParameters, &exploded); @@ +660,5 @@ > + kTimeFormatSeconds, &exploded, > + dateValue); > + > + nsCString timestampString(LOG_ENTRY_TIMESTAMP); > + timestampString.ReplaceSubstring("$S", NS_ConvertUTF16toUTF8(dateValue).get()); I don't think we have completely abandoned compatibility with external strings yet (or I hope not as I still rely on that in some of my code) so could you use MsgReplaceSubstring here instead of ReplaceSubstring?
Attachment #8629666 - Flags: review?(rkent) → review+
Thanks, made the changes, in both files.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 43.0
You need to log in before you can comment on or make changes to this bug.