Bug 6556 - Only mass-check emails that have been read
Summary: Only mass-check emails that have been read
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Masses (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-19 11:00 UTC by Darxus
Modified: 2011-11-03 19:47 UTC (History)
3 users (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 Darxus 2011-03-19 11:00:19 UTC 
Maildirs contain the subdirectories "cur" (read emails), "new" (unread emails), and "tmp".  I'd like a flag for mass-check to only use the "cur" directory.

I think it would be appropriate to recommend using it to everyone except for spam traps (with no email addresses that were ever valid)?

Currently I'm doing this by copying only the "cur" directory from my maildirs to a new directory used only for mass-check.
Comment 1 Darxus 2011-04-07 17:19:03 UTC 
Specs for Maildir: 
http://cr.yp.to/proto/maildir.html

Has been read if filename matches /:.*2,\D*S/
Basically, ends with "S".  Example:  1302116417.16310_2.panic:2,S


Specs for mbox:
http://wiki1.dovecot.org/MailboxFormat/mbox

Has been read if Status header matches /R/.
Comment 2 AXB 2011-04-07 17:27:28 UTC 
(In reply to comment #1)
> Specs for Maildir: 
> http://cr.yp.to/proto/maildir.html
> 
> Has been read if filename matches /:.*2,\D*S/
> Basically, ends with "S".  Example:  1302116417.16310_2.panic:2,S
> 
> 
> Specs for mbox:
> http://wiki1.dovecot.org/MailboxFormat/mbox
> 
> Has been read if Status header matches /R/.

there is no 100% standard for Maildir file naming.
the S & R may be used by a few, but not all.

IMO, you can easily only replicate read or not read to your MC folder using lots of availabel tools.
It's hardly in SA's scope to do this.
Comment 3 Darxus 2011-04-07 17:31:00 UTC 
AXB, is there a reason a patch wouldn't be accepted?  Wouldn't it significantly reduce the effort to maintain folders for use with mass-check (for anybody using mail software that uses these flags)?

And sure, I could just do "find ~/Maildir/cur -name "*S" | xargs -I foo cp foo ~/ham-for-masscheck ; mass-check ham:dir:~/ham-for-masscheck"

But isn't it silly not to just implement it in mass-check?
Comment 4 AXB 2011-04-07 17:43:33 UTC 
(In reply to comment #3)
> AXB, is there a reason a patch wouldn't be accepted?  Wouldn't it significantly
> reduce the effort to maintain folders for use with mass-check (for anybody
> using mail software that uses these flags)?
> And sure, I could just do "find ~/Maildir/cur -name "*S" | xargs -I foo cp foo
> ~/ham-for-masscheck ; mass-check ham:dir:~/ham-for-masscheck"
> 
> But isn't it silly not to just implement it in mass-check?

nobody intends to stop you from submitting a patch.
Comment 5 Bernie Innocenti 2011-04-21 22:55:56 UTC 
FWIW, it would simplify my setup if the masscheck script supported skipping unread email in mailboxes. Currently, I have to filter my inbox into a separate ham folder to avoid processing messages that I haven't yet looked at and could contain spam.

This is what I'm currently doing as a work-around:

nice ionice -c2 -n6 rsync -al '--include=*:2,*S*' '--exclude=*' --delete-after \
   --link-dest=/mail/bernie/cur/ /mail/bernie/cur/ /mail/bernie/masscheck/confirmed_ham/cur/

nice ionice -c2 -n6 rsync -al '--include=*:2,*S*' '--exclude=*' --delete-after \
   --link-dest=/mail/bernie/.@FSF/cur/ /mail/bernie/.@FSF/cur/ /mail/bernie/masscheck/confirmed_ham_fsf/cur/
Comment 6 Kevin A. McGrail 2011-11-03 19:47:48 UTC 
I can argue the necessity of this patch both ways.  However, in the end, masscheck is intended to be run on hand-classified mail.  

Running it on an Inbox seems a bit odd to me and the tools to copy it for the purposes of masscheck exist (and are documented in this ticket).

Closing as wontfix but I wouldn't turn down applying a patch for the option to do this.  But it should be a non-default option for backwards compatibility.