From: "Ted Zlatanov" <tzz@lifelogs.com>
Cc: "Ding Mailing List" <ding@gnus.org>
Subject: Re: spam handling in No Gnus 0.3
Date: 21 Mar 2006 11:06:43 -0500 [thread overview]
Message-ID: <4n8xr3dbos.fsf@asimov.bwh.harvard.edu> (raw)
In-Reply-To: <y20bqw247av.fsf@newsserver.nospam.net> (Alberto L.'s message of "Sun, 19 Mar 2006 10:29:28 -0800")
The following message is a courtesy copy of an article
that has been posted to gnu.emacs.gnus as well.
On 19 Mar 2006, alberto.l@nospam.net wrote:
> I have recently upgraded to No Gnus 0.3 and I have some comments about
> spam handling.
>
> I use the nnfolder backend for e-mail, spam-split with bogofilter, and
> gnus-registry. New messages classified as ham appear in
> mail.incoming. If I find there spam, then I mark it as spam and, on
> exiting, the message is registered as spam with bogofilter, and moved
> to mail.spam.save.
>
> Later on I double check mail.spam.save (a
> gnus-group-spam-classification-spam group), where I can mark ham
> erroneously classified as spam. On exiting, spam is deleted, and ham
> is unregistered as spam, and registered as ham with bogofilter.
>
> The first problem I find is that when spam messages are deleted from
> mail.spam.save, they are UN-registered as spam with bogofilter, which
> is obviously undesirable.
>
> I have checked the elisp code in spam.el. The summary-prepare-exit
> hook routine checks what marks changed in mail.spam.save, and for each
> article whone mark changed from spam to ham (AND viceversa), and was
> registered as spam, it is unregistered as spam. The articles I marked
> as spam have no mark when the group is entered, then they are
> automatically marked as spam with a summary-prepare hook routine
> (because the group is classified as spam). When checks are done on
> exiting, all spam articles unchanged by the user are considered
> "changed" because their mark was (automatically) changed. And, even
> if the mark says "spam", they are unregistered as spam: this appears
> plain wrong to me.
>
> It is quite easy to fix the above, one has to move
> "spam-mark-junk-as-spam-routine" to before (rather than after)
> initializing the "spam-old-articles" in the prepare-summary spam hook:
>
(defun spam-summary-prepare ()
(spam-mark-junk-as-spam-routine)
(setq spam-old-articles
(list (cons 'ham (spam-list-articles gnus-newsgroup-articles 'ham))
(cons 'spam (spam-list-articles gnus-newsgroup-articles 'spam)))))
> I recommend adopting the above modification.
The whole point of the order is that old articles are from before
unseen articles got marked as spam. So I don't think this fix will do
it.
Could you use the CVS version of Gnus, and we can start thinking of a
solution against it?
> I use a second group mail.spam.train to train bogofilter both with ham
> and spam messages. The group is "gnus-group-spam-classification-ham".
> On exiting, articles marked as ham are registered as ham with
> bogofilter. Articles marked as spam are registered as spam with
> bogofilter and automatically moved to mail.spam.save.
>
> The problem is that ham articles are not moved or deleted, and when I
> re-enter the group in order to expire the article (I have immediate
> expiration) to avoid double registrations, on exiting the ham articles
> are unregistered as ham, which is again quite undesirable.
>
> This happens because, in the summary-prepare-exit spam routine, the
> expired articles have the "expirable" mark, which is not a ham mark,
> thus the code judges that their classification has changed, and since
> gnus-registry remembers they were registered as ham, they are
> unregistered. Something similar happens if one explicitly expires
> spam in spam groups. There are two possible solutions:
> - add the expirable mark in the list of both ham and spam marks
> - change the code, preventing expirable articles to be considered as
> articles where the user changed their ham/spam classification.
>
> I think that the second solution is more appropriate: when I expire
> articles I mean to delete them, and not to change their ham/spam
> classification. In order to do that, spam.el has to be changed as
> follows:
>
***************
*** 1343,1352 ****
(dolist (backend (spam-backend-list))
(let (unregister-list)
(dolist (article changed-articles)
(let ((id (spam-fetch-field-message-id-fast article)))
(when (spam-log-unregistration-needed-p
id 'process classification backend)
! (push article unregister-list))))
;; call spam-register-routine with specific articles to unregister,
;; when there are articles to unregister and the check is enabled
(when (and unregister-list (symbol-value backend))
--- 1343,1355 ----
(dolist (backend (spam-backend-list))
(let (unregister-list)
(dolist (article changed-articles)
+ ;; do not unregister articles marked as expirable
+ (unless (eq gnus-expirable-mark
+ (gnus-summary-article-mark article))
(let ((id (spam-fetch-field-message-id-fast article)))
(when (spam-log-unregistration-needed-p
id 'process classification backend)
! (push article unregister-list)))))
;; call spam-register-routine with specific articles to unregister,
;; when there are articles to unregister and the check is enabled
(when (and unregister-list (symbol-value backend))
Expirable articles should probably be ignored, so I think this
modification is OK. Does anyone else see a problem?
Ted
next parent reply other threads:[~2006-03-21 16:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <y20bqw247av.fsf@newsserver.nospam.net>
2006-03-21 16:06 ` Ted Zlatanov [this message]
2006-04-11 16:10 ` Lars Magne Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4n8xr3dbos.fsf@asimov.bwh.harvard.edu \
--to=tzz@lifelogs.com \
--cc=ding@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).