* Gnus manual update
@ 2006-02-03 20:59 Chong Yidong
2006-02-06 19:18 ` Ted Zlatanov
0 siblings, 1 reply; 30+ messages in thread
From: Chong Yidong @ 2006-02-03 20:59 UTC (permalink / raw)
Cc: Ted Zlatanov
I propose these changes to the part of the Gnus manual, to make it
easier to understand how the Spam package works. Unfortunately, the
diff by itself is rather difficult to read; you may want to use ediff
to compare, or apply the patch and read the texinfo file directly.
*** emacs/man/gnus.texi.~1.65.~ 2006-02-03 15:53:29.000000000 -0500
--- emacs/man/gnus.texi 2006-02-03 15:53:08.000000000 -0500
***************
*** 797,803 ****
* Moderation:: What to do if you're a moderator.
* Image Enhancements:: Modern versions of Emacs/XEmacs can display images.
* Fuzzy Matching:: What's the big fuzz?
! * Thwarting Email Spam:: A how-to on avoiding unsolicited commercial email.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
--- 797,804 ----
* Moderation:: What to do if you're a moderator.
* Image Enhancements:: Modern versions of Emacs/XEmacs can display images.
* Fuzzy Matching:: What's the big fuzz?
! * Thwarting Email Spam:: Simple ways to avoid unsolicited commercial email.
! * Spam Package:: A package for filtering and processing spam.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
***************
*** 816,822 ****
* X-Face:: Display a funky, teensy black-and-white image.
* Face:: Display a funkier, teensier colored image.
! * Smileys:: Show all those happy faces the way they were meant to be shown.
* Picons:: How to display pictures of what you're reading.
* XVarious:: Other XEmacsy Gnusey variables.
--- 817,824 ----
* X-Face:: Display a funky, teensy black-and-white image.
* Face:: Display a funkier, teensier colored image.
! * Smileys:: Show all those happy faces the way they were
! meant to be shown.
* Picons:: How to display pictures of what you're reading.
* XVarious:: Other XEmacsy Gnusey variables.
***************
*** 826,853 ****
* Anti-Spam Basics:: Simple steps to reduce the amount of spam.
* SpamAssassin:: How to use external anti-spam tools.
* Hashcash:: Reduce spam by burning CPU time.
- * Filtering Spam Using The Spam ELisp Package::
- * Filtering Spam Using Statistics with spam-stat::
! Filtering Spam Using The Spam ELisp Package
! * Spam ELisp Package Sequence of Events::
! * Spam ELisp Package Filtering of Incoming Mail::
! * Spam ELisp Package Global Variables::
! * Spam ELisp Package Configuration Examples::
! * Blacklists and Whitelists::
! * BBDB Whitelists::
! * Gmane Spam Reporting::
! * Anti-spam Hashcash Payments::
! * Blackholes::
! * Regular Expressions Header Matching::
! * Bogofilter::
! * ifile spam filtering::
! * spam-stat spam filtering::
! * SpamOracle::
! * Extending the Spam ELisp package::
! Filtering Spam Using Statistics with spam-stat
* Creating a spam-stat dictionary::
* Splitting mail using spam-stat::
--- 828,846 ----
* Anti-Spam Basics:: Simple steps to reduce the amount of spam.
* SpamAssassin:: How to use external anti-spam tools.
* Hashcash:: Reduce spam by burning CPU time.
! Spam Package
! * Spam Package Introduction::
! * Filtering Incoming Mail::
! * Detecting Spam in Groups::
! * Spam and Ham Processors::
! * Spam Package Configuration Examples::
! * Spam Back Ends::
! * Extending the Spam package::
! * Spam Statistics Package::
! Spam Statistics Package
* Creating a spam-stat dictionary::
* Splitting mail using spam-stat::
***************
*** 20711,20717 ****
* Fetching a Group:: Starting Gnus just to read a group.
* Image Enhancements:: Modern versions of Emacs/XEmacs can display images.
* Fuzzy Matching:: What's the big fuzz?
! * Thwarting Email Spam:: A how-to on avoiding unsolicited commercial email.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
@end menu
--- 20704,20711 ----
* Fetching a Group:: Starting Gnus just to read a group.
* Image Enhancements:: Modern versions of Emacs/XEmacs can display images.
* Fuzzy Matching:: What's the big fuzz?
! * Thwarting Email Spam:: Simple ways to avoid unsolicited commercial email.
! * Spam Package:: A package for filtering and processing spam.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
@end menu
***************
*** 22378,22385 ****
* Anti-Spam Basics:: Simple steps to reduce the amount of spam.
* SpamAssassin:: How to use external anti-spam tools.
* Hashcash:: Reduce spam by burning CPU time.
- * Filtering Spam Using The Spam ELisp Package::
- * Filtering Spam Using Statistics with spam-stat::
@end menu
@node The problem of spam
--- 22372,22377 ----
***************
*** 22695,22735 ****
customized mail filtering scripts. Improvements in this area would be
a useful contribution, however.
! @node Filtering Spam Using The Spam ELisp Package
! @subsection Filtering Spam Using The Spam ELisp Package
@cindex spam filtering
@cindex spam
! The idea behind @file{spam.el} is to have a control center for spam detection
! and filtering in Gnus. To that end, @file{spam.el} does two things: it
! filters new mail, and it analyzes mail known to be spam or ham.
! @dfn{Ham} is the name used throughout @file{spam.el} to indicate
! non-spam messages.
@cindex spam-initialize
! First of all, you @strong{must} run the function
! @code{spam-initialize} to autoload @code{spam.el} and to install the
! @code{spam.el} hooks. There is one exception: if you use the
! @code{spam-use-stat} (@pxref{spam-stat spam filtering}) setting, you
! should turn it on before @code{spam-initialize}:
@example
- (setq spam-use-stat t) ;; if needed
(spam-initialize)
@end example
! So, what happens when you load @file{spam.el}?
!
! First, some hooks will get installed by @code{spam-initialize}. There
! are some hooks for @code{spam-stat} so it can save its databases, and
! there are hooks so interesting things will happen when you enter and
! leave a group. More on the sequence of events later (@pxref{Spam
! ELisp Package Sequence of Events}).
!
! You get the following keyboard commands:
@table @kbd
-
@item M-d
@itemx M s x
@itemx S x
--- 22687,22793 ----
customized mail filtering scripts. Improvements in this area would be
a useful contribution, however.
! @node Spam Package
! @section Spam Package
@cindex spam filtering
@cindex spam
! The Spam package provides Gnus with a centralized mechanism for
! detecting and filtering spam. It filters new mail, and processes
! messages according to whether they are spam or ham. (@dfn{Ham} is the
! name used throughout this manual to indicate non-spam messages.)
!
! @menu
! * Spam Package Introduction::
! * Filtering Incoming Mail::
! * Detecting Spam in Groups::
! * Spam and Ham Processors::
! * Spam Package Configuration Examples::
! * Spam Back Ends::
! * Extending the Spam package::
! * Spam Statistics Package::
! @end menu
!
! @node Spam Package Introduction
! @subsection Spam Package Introduction
! @cindex spam filtering
! @cindex spam filtering sequence of events
! @cindex spam
!
! You must read this section to understand how the Spam package works.
! Do not skip, speed-read, or glance through this section.
@cindex spam-initialize
! @vindex spam-use-stat
! To use the Spam package, you @strong{must} first run the function
! @code{spam-initialize}:
@example
(spam-initialize)
@end example
! This autoloads @code{spam.el} and installs the various hooks necessary
! to let the Spam package do its job. In order to make use of the Spam
! package, you have to set up certain group parameters and variables,
! which we will describe below. All of the variables controlling the
! Spam package can be found in the @samp{spam} customization group.
!
! There are two ``contact points'' between the Spam package and the rest
! of Gnus: checking new mail for spam, and leaving a group.
!
! Checking new mail for spam is done in one of two ways: while splitting
! incoming mail, or when you enter a group.
!
! The first way, checking for spam while splitting incoming mail, is
! suited to mail back ends such as @code{nnml} or @code{nnimap}, where
! new mail appears in a single spool file. The Spam package processes
! incoming mail, and sends mail considered to be spam to a designated
! ``spam'' group. @xref{Filtering Incoming Mail}.
!
! The second way is suited to back ends such as @code{nntp}, which have
! no incoming mail spool, or back ends where the server is in charge of
! splitting incoming mail. In this case, when you enter a Gnus group,
! the unseen or unread messages in that group are checked for spam.
! Detected spam messages are marked as spam. @xref{Detecting Spam in
! Groups}.
!
! @cindex spam back ends
! In either case, you have to tell the Spam package what method to use
! to detect spam messages. There are several methods, or @dfn{spam back
! ends} (not to be confused with Gnus back ends!) to choose from: spam
! ``blacklists'' and ``whitelists'', dictionary-based filters, and so
! forth. @xref{Spam Back Ends}.
!
! In the Gnus summary buffer, messages that have been identified as spam
! always appear with a @samp{$} symbol.
!
! The Spam package divides Gnus groups into three categories: ham
! groups, spam groups, and unclassified groups. You should mark each of
! the groups you subscribe to as either a ham group or a spam group,
! using the @code{spam-contents} group parameter (@pxref{Group
! Parameters}). Spam groups have a special property: when you enter a
! spam group, all unseen articles are marked as spam. Thus, mail split
! into a spam group is automatically marked as spam.
!
! Identifying spam messages is only half of the Spam package's job. The
! second half comes into play whenever you exit a group buffer. At this
! point, the Spam package does several things:
!
! First, it calls @dfn{spam and ham processors} to process the articles
! according to whether they are spam or ham. There is a pair of spam
! and ham processors associated with each spam back end, and what the
! processors do depends on the back end. At present, the main role of
! spam and ham processors is for dictionary-based spam filters: they add
! the contents of the messages in the group to the filter's dictionary,
! to improve its ability to detect future spam. The @code{spam-process}
! group parameter specifies what spam processors to use. @xref{Spam and
! Ham Processors}.
!
! If the spam filter failed to mark a spam message, you can mark it
! yourself, so that the message is processed as spam when you exit the
! group:
@table @kbd
@item M-d
@itemx M s x
@itemx S x
***************
*** 22737,22925 ****
@kindex S x
@kindex M s x
@findex gnus-summary-mark-as-spam
! @code{gnus-summary-mark-as-spam}.
!
! Mark current article as spam, showing it with the @samp{$} mark.
! Whenever you see a spam article, make sure to mark its summary line
! with @kbd{M-d} before leaving the group. This is done automatically
! for unread articles in @emph{spam} groups.
!
! @item M s t
! @itemx S t
! @kindex M s t
! @kindex S t
! @findex spam-bogofilter-score
! @code{spam-bogofilter-score}.
!
! You must have Bogofilter installed for that command to work properly.
!
! @xref{Bogofilter}.
!
@end table
! Also, when you load @file{spam.el}, you will be able to customize its
! variables. Try @code{customize-group} on the @samp{spam} variable
! group.
!
! @menu
! * Spam ELisp Package Sequence of Events::
! * Spam ELisp Package Filtering of Incoming Mail::
! * Spam ELisp Package Global Variables::
! * Spam ELisp Package Configuration Examples::
! * Blacklists and Whitelists::
! * BBDB Whitelists::
! * Gmane Spam Reporting::
! * Anti-spam Hashcash Payments::
! * Blackholes::
! * Regular Expressions Header Matching::
! * Bogofilter::
! * ifile spam filtering::
! * spam-stat spam filtering::
! * SpamOracle::
! * Extending the Spam ELisp package::
! @end menu
! @node Spam ELisp Package Sequence of Events
! @subsubsection Spam ELisp Package Sequence of Events
! @cindex spam filtering
! @cindex spam filtering sequence of events
! @cindex spam
! You must read this section to understand how @code{spam.el} works.
! Do not skip, speed-read, or glance through this section.
! There are two @emph{contact points}, if you will, between
! @code{spam.el} and the rest of Gnus: checking new mail for spam, and
! leaving a group.
!
! Getting new mail is done in one of two ways. You can either split
! your incoming mail or you can classify new articles as ham or spam
! when you enter the group.
!
! Splitting incoming mail is better suited to mail backends such as
! @code{nnml} or @code{nnimap} where new mail appears in a single file
! called a @dfn{Spool File}. See @xref{Spam ELisp Package Filtering of
! Incoming Mail}.
!
! For backends such as @code{nntp} there is no incoming mail spool, so
! an alternate mechanism must be used. This may also happen for
! backends where the server is in charge of splitting incoming mail, and
! Gnus does not do further splitting. The @code{spam-autodetect} and
! @code{spam-autodetect-methods} group parameters (accessible with
! @kbd{G c} and @kbd{G p} as usual), and the corresponding variables
! @code{gnus-spam-autodetect-methods} and
! @code{gnus-spam-autodetect-methods} (accessible with @kbd{M-x
! customize-variable} as usual).
!
! When @code{spam-autodetect} is used, it hooks into the process of
! entering a group. Thus, entering a group with unseen or unread
! articles becomes the substitute for checking incoming mail. Whether
! only unseen articles or all unread articles will be processed is
! determined by the @code{spam-autodetect-recheck-messages}. When set
! to @code{t}, unread messages will be rechecked.
!
! @code{spam-autodetect} grants the user at once more and less control
! of spam filtering. The user will have more control over each group's
! spam methods, so for instance the @samp{ding} group may have
! @code{spam-use-BBDB} as the autodetection method, while the
! @samp{suspect} group may have the @code{spam-use-blacklist} and
! @code{spam-use-bogofilter} methods enabled. Every article detected to
! be spam will be marked with the spam mark @samp{$} and processed on
! exit from the group as normal spam. The user has less control over
! the @emph{sequence} of checks, as he might with @code{spam-split}.
!
! When the newly split mail goes into groups, or messages are
! autodetected to be ham or spam, those groups must be exited (after
! entering, if needed) for further spam processing to happen. It
! matters whether the group is considered a ham group, a spam group, or
! is unclassified, based on its @code{spam-content} parameter
! (@pxref{Spam ELisp Package Global Variables}). Spam groups have the
! additional characteristic that, when entered, any unseen or unread
! articles (depending on the @code{spam-mark-only-unseen-as-spam}
! variable) will be marked as spam. Thus, mail split into a spam group
! gets automatically marked as spam when you enter the group.
!
! So, when you exit a group, the @code{spam-processors} are applied, if
! any are set, and the processed mail is moved to the
! @code{ham-process-destination} or the @code{spam-process-destination}
! depending on the article's classification. If the
! @code{ham-process-destination} or the @code{spam-process-destination},
! whichever is appropriate, are @code{nil}, the article is left in the
! current group.
!
! If a spam is found in any group (this can be changed to only non-spam
! groups with @code{spam-move-spam-nonspam-groups-only}), it is
! processed by the active @code{spam-processors} (@pxref{Spam ELisp
! Package Global Variables}) when the group is exited. Furthermore, the
! spam is moved to the @code{spam-process-destination} (@pxref{Spam
! ELisp Package Global Variables}) for further training or deletion.
! You have to load the @code{gnus-registry.el} package and enable the
! @code{spam-log-to-registry} variable if you want spam to be processed
! no more than once. Thus, spam is detected and processed everywhere,
! which is what most people want. If the
! @code{spam-process-destination} is @code{nil}, the spam is marked as
expired, which is usually the right thing to do.
- If spam can not be moved---because of a read-only backend such as
- @acronym{NNTP}, for example, it will be copied.
-
- If a ham mail is found in a ham group, as determined by the
- @code{ham-marks} parameter, it is processed as ham by the active ham
- @code{spam-processor} when the group is exited. With the variables
- @code{spam-process-ham-in-spam-groups} and
- @code{spam-process-ham-in-nonham-groups} the behavior can be further
- altered so ham found anywhere can be processed. You have to load the
- @code{gnus-registry.el} package and enable the
- @code{spam-log-to-registry} variable if you want ham to be processed
- no more than once. Thus, ham is detected and processed only when
- necessary, which is what most people want. More on this in
- @xref{Spam ELisp Package Configuration Examples}.
-
- If ham can not be moved---because of a read-only backend such as
- @acronym{NNTP}, for example, it will be copied.
-
If all this seems confusing, don't worry. Soon it will be as natural
as typing Lisp one-liners on a neural interface@dots{} err, sorry, that's
50 years in the future yet. Just trust us, it's not so bad.
! @node Spam ELisp Package Filtering of Incoming Mail
! @subsubsection Spam ELisp Package Filtering of Incoming Mail
@cindex spam filtering
@cindex spam filtering incoming mail
@cindex spam
! To use the @file{spam.el} facilities for incoming mail filtering, you
! must add the following to your fancy split list
! @code{nnmail-split-fancy} or @code{nnimap-split-fancy}:
@example
(: spam-split)
@end example
! Note that the fancy split may be called @code{nnmail-split-fancy} or
! @code{nnimap-split-fancy}, depending on whether you use the nnmail or
! nnimap back ends to retrieve your mail.
!
! Also, @code{spam-split} will not modify incoming mail in any way.
!
! The @code{spam-split} function will process incoming mail and send the
! mail considered to be spam into the group name given by the variable
! @code{spam-split-group}. By default that group name is @samp{spam},
! but you can customize @code{spam-split-group}. Make sure the contents
! of @code{spam-split-group} are an @emph{unqualified} group name, for
! instance in an @code{nnimap} server @samp{your-server} the value
! @samp{spam} will turn out to be @samp{nnimap+your-server:spam}. The
! value @samp{nnimap+server:spam}, therefore, is wrong and will
! actually give you the group
! @samp{nnimap+your-server:nnimap+server:spam} which may or may not
! work depending on your server's tolerance for strange group names.
!
! You can also give @code{spam-split} a parameter,
! e.g. @code{spam-use-regex-headers} or @code{"maybe-spam"}. Why is
! this useful?
! Take these split rules (with @code{spam-use-regex-headers} and
! @code{spam-use-blackholes} set):
@example
nnimap-split-fancy '(|
--- 22795,22897 ----
@kindex S x
@kindex M s x
@findex gnus-summary-mark-as-spam
! @findex gnus-summary-mark-as-spam
! Mark current article as spam, showing it with the @samp{$} mark
! (@code{gnus-summary-mark-as-spam}).
@end table
! @noindent
! Similarly, you can unmark an article if it has been erroneously marked
! as spam. @xref{Setting Marks}.
! Normally, a ham message found in a non-ham group is not processed as
! ham---the rationale is that it should be moved into a ham group for
! further processing (see below). However, you can force these articles
! to be processed as ham by setting
! @code{spam-process-ham-in-spam-groups} and
! @code{spam-process-ham-in-nonham-groups}.
! @vindex gnus-ham-process-destinations
! @vindex gnus-spam-process-destinations
! The second thing that the Spam package does when you exit a group is
! to move ham articles out of spam groups, and spam articles out of ham
! groups. Ham in a spam group is moved to the group specified by the
! variable @code{gnus-ham-process-destinations}, or the group parameter
! @code{ham-process-destination}. Spam in a ham group is moved to the
! group specified by the variable @code{gnus-spam-process-destinations},
! or the group parameter @code{spam-process-destination}. If these
! variables are not set, the articles are left in their current group.
! If an article cannot not be moved (e.g., with a read-only backend such
! as @acronym{NNTP}), it is copied.
!
! If an article is moved to another group, it is processed again when
! you visit the new group. Normally, this is not a problem, but if you
! want each article to be processed only once, load the
! @code{gnus-registry.el} package and set the variable
! @code{spam-log-to-registry} to @code{t}. @xref{Spam Package
! Configuration Examples}.
!
! Normally, spam groups ignore @code{gnus-spam-process-destinations}.
! However, if you set @code{spam-move-spam-nonspam-groups-only} to
! @code{nil}, spam will also be moved out of spam groups, depending on
! the @code{spam-process-destination} parameter.
! The final thing the Spam package does is to mark spam articles as
expired, which is usually the right thing to do.
If all this seems confusing, don't worry. Soon it will be as natural
as typing Lisp one-liners on a neural interface@dots{} err, sorry, that's
50 years in the future yet. Just trust us, it's not so bad.
! @node Filtering Incoming Mail
! @subsection Filtering Incoming Mail
@cindex spam filtering
@cindex spam filtering incoming mail
@cindex spam
! To use the Spam package to filter incoming mail, you must first set up
! fancy mail splitting. @xref{Fancy Mail Splitting}. The Spam package
! defines a special splitting function that you can add to your fancy
! split variable (either @code{nnmail-split-fancy} or
! @code{nnimap-split-fancy}, depending on your mail back end):
@example
(: spam-split)
@end example
! @vindex spam-split-group
! @noindent
! The @code{spam-split} function scans incoming mail according to your
! chosen spam back end(s), and sends messages identified as spam to a
! spam group. By default, the spam group is a group named @samp{spam},
! but you can change this by customizing @code{spam-split-group}. Make
! sure the contents of @code{spam-split-group} are an unqualified group
! name. For instance, in an @code{nnimap} server @samp{your-server},
! the value @samp{spam} means @samp{nnimap+your-server:spam}. The value
! @samp{nnimap+server:spam} is therefore wrong---it gives the group
! @samp{nnimap+your-server:nnimap+server:spam}.
!
! @code{spam-split} does not modify the contents of messages in any way.
! @vindex nnimap-split-download-body
! Note for IMAP users: if you use the @code{spam-check-bogofilter},
! @code{spam-check-ifile}, and @code{spam-check-stat} spam back ends,
! you should also set set the variable @code{nnimap-split-download-body}
! to @code{t}. These spam back ends are most useful when they can
! ``scan'' the full message body. By default, the nnimap back end only
! retrieves the message headers; @code{nnimap-split-download-body} tells
! it to retrieve the message bodies as well. We don't set this by
! default because it will slow @acronym{IMAP} down, and that is not an
! appropriate decision to make on behalf of the user. @xref{Splitting
! in IMAP}.
!
! You have to specify one or more spam back ends for @code{spam-split}
! to use, by setting the @code{spam-use-*} variables. @xref{Spam Back
! Ends}. Normally, @code{spam-split} simply uses all the spam back ends
! you enabled in this way. However, you can tell @code{spam-split} to
! use only some of them. Why this is useful? Suppose you are using the
! @code{spam-use-regex-headers} and @code{spam-use-blackholes} spam back
! ends, and the following split rule:
@example
nnimap-split-fancy '(|
***************
*** 22929,22949 ****
"mail")
@end example
! Now, the problem is that you want all ding messages to make it to the
! ding folder. But that will let obvious spam (for example, spam
! detected by SpamAssassin, and @code{spam-use-regex-headers}) through,
! when it's sent to the ding list. On the other hand, some messages to
! the ding list are from a mail server in the blackhole list, so the
! invocation of @code{spam-split} can't be before the ding rule.
!
! You can let SpamAssassin headers supersede ding rules, but all other
! @code{spam-split} rules (including a second invocation of the
! regex-headers check) will be after the ding rule:
@example
nnimap-split-fancy
'(|
! ;; @r{all spam detected by @code{spam-use-regex-headers} goes to @samp{regex-spam}}
(: spam-split "regex-spam" 'spam-use-regex-headers)
(any "ding" "ding")
;; @r{all other spam detected by spam-split goes to @code{spam-split-group}}
--- 22901,22923 ----
"mail")
@end example
! @noindent
! The problem is that you want all ding messages to make it to the ding
! folder. But that will let obvious spam (for example, spam detected by
! SpamAssassin, and @code{spam-use-regex-headers}) through, when it's
! sent to the ding list. On the other hand, some messages to the ding
! list are from a mail server in the blackhole list, so the invocation
! of @code{spam-split} can't be before the ding rule.
!
! The solution is to let SpamAssassin headers supersede ding rules, and
! perform the other @code{spam-split} rules (including a second
! invocation of the regex-headers check) after the ding rule. This is
! done by passing a parameter to @code{spam-split}:
@example
nnimap-split-fancy
'(|
! ;; @r{spam detected by @code{spam-use-regex-headers} goes to @samp{regex-spam}}
(: spam-split "regex-spam" 'spam-use-regex-headers)
(any "ding" "ding")
;; @r{all other spam detected by spam-split goes to @code{spam-split-group}}
***************
*** 22952,23009 ****
"mail")
@end example
This lets you invoke specific @code{spam-split} checks depending on
! your particular needs, and to target the results of those checks to a
particular spam group. You don't have to throw all mail into all the
spam tests. Another reason why this is nice is that messages to
mailing lists you have rules for don't have to have resource-intensive
blackhole checks performed on them. You could also specify different
spam checks for your nnmail split vs. your nnimap split. Go crazy.
! You should still have specific checks such as
! @code{spam-use-regex-headers} set to @code{t}, even if you
! specifically invoke @code{spam-split} with the check. The reason is
! that when loading @file{spam.el}, some conditional loading is done
! depending on what @code{spam-use-xyz} variables you have set. This
! is usually not critical, though.
!
! @emph{Note for IMAP users}
!
! The boolean variable @code{nnimap-split-download-body} needs to be
! set, if you want to split based on the whole message instead of just
! the headers. By default, the nnimap back end will only retrieve the
! message headers. If you use @code{spam-check-bogofilter},
! @code{spam-check-ifile}, or @code{spam-check-stat} (the splitters that
! can benefit from the full message body), you should set this variable.
! It is not set by default because it will slow @acronym{IMAP} down, and
! that is not an appropriate decision to make on behalf of the user.
!
! @xref{Splitting in IMAP}.
!
! @emph{TODO: spam.el needs to provide a uniform way of training all the
! statistical databases. Some have that functionality built-in, others
! don't.}
! @node Spam ELisp Package Global Variables
! @subsubsection Spam ELisp Package Global Variables
@cindex spam filtering
@cindex spam filtering variables
@cindex spam variables
@cindex spam
@vindex gnus-spam-process-newsgroups
! The concepts of ham processors and spam processors are very important.
! Ham processors and spam processors for a group can be set with the
! @code{spam-process} group parameter, or the
! @code{gnus-spam-process-newsgroups} variable. Ham processors take
! mail known to be non-spam (@emph{ham}) and process it in some way so
! that later similar mail will also be considered non-spam. Spam
! processors take mail known to be spam and process it so similar spam
! will be detected later.
!
! The format of the spam or ham processor entry used to be a symbol,
! but now it is a @sc{cons} cell. See the individual spam processor entries
! for more information.
@vindex gnus-spam-newsgroup-contents
Gnus learns from the spam you get. You have to collect your spam in
--- 22926,22993 ----
"mail")
@end example
+ @noindent
This lets you invoke specific @code{spam-split} checks depending on
! your particular needs, and target the results of those checks to a
particular spam group. You don't have to throw all mail into all the
spam tests. Another reason why this is nice is that messages to
mailing lists you have rules for don't have to have resource-intensive
blackhole checks performed on them. You could also specify different
spam checks for your nnmail split vs. your nnimap split. Go crazy.
! You should set the @code{spam-use-*} variables for whatever spam back
! ends you intend to use. The reason is that when loading
! @file{spam.el}, some conditional loading is done depending on what
! @code{spam-use-xyz} variables you have set. @xref{Spam Back Ends}.
!
! @c @emph{TODO: spam.el needs to provide a uniform way of training all the
! @c statistical databases. Some have that functionality built-in, others
! @c don't.}
!
! @node Detecting Spam in Groups
! @subsection Detecting Spam in Groups
!
! To detect spam when visiting a group, set the group's
! @code{spam-autodetect} and @code{spam-autodetect-methods} group
! parameters. These are accessible with @kbd{G c} or @kbd{G p}, as
! usual (@pxref{Group Parameters}).
!
! You should set the @code{spam-use-*} variables for whatever spam back
! ends you intend to use. The reason is that when loading
! @file{spam.el}, some conditional loading is done depending on what
! @code{spam-use-xyz} variables you have set.
!
! By default, only unseen articles are processed for spam. You can
! force Gnus to recheck all messages in the group by setting the
! variable @code{spam-autodetect-recheck-messages} to @code{t}.
!
! If you use the @code{spam-autodetect} method of checking for spam, you
! can specify different spam detection methods for different groups.
! For instance, the @samp{ding} group may have @code{spam-use-BBDB} as
! the autodetection method, while the @samp{suspect} group may have the
! @code{spam-use-blacklist} and @code{spam-use-bogofilter} methods
! enabled. Unlike with @code{spam-split}, you don't have any control
! over the @emph{sequence} of checks, but this is probably unimportant.
! @node Spam and Ham Processors
! @subsection Spam and Ham Processors
@cindex spam filtering
@cindex spam filtering variables
@cindex spam variables
@cindex spam
@vindex gnus-spam-process-newsgroups
! Spam and ham processors specify special actions to take when you exit
! a group buffer. Spam processors act on spam messages, and ham
! processors on ham messages. At present, the main role of these
! processors is to update the dictionaries of dictionary-based spam back
! ends such as Bogofilter (@pxref{Bogofilter}) and the Spam Statistics
! package (@pxref{Spam Statistics Filtering}).
!
! The spam and ham processors that apply to each group are determined by
! the group's@code{spam-process} group parameter. If this group
! parameter is not defined, they are determined by the variable
! @code{gnus-spam-process-newsgroups}.
@vindex gnus-spam-newsgroup-contents
Gnus learns from the spam you get. You have to collect your spam in
***************
*** 23157,23164 ****
only unseen articles or all unread articles should be checked for
spam. It is recommended that you leave it off.
! @node Spam ELisp Package Configuration Examples
! @subsubsection Spam ELisp Package Configuration Examples
@cindex spam filtering
@cindex spam filtering configuration examples
@cindex spam configuration examples
--- 23141,23148 ----
only unseen articles or all unread articles should be checked for
spam. It is recommended that you leave it off.
! @node Spam Package Configuration Examples
! @subsection Spam Package Configuration Examples
@cindex spam filtering
@cindex spam filtering configuration examples
@cindex spam configuration examples
***************
*** 23283,23293 ****
Because of the @code{gnus-group-spam-classification-spam} entry, all
messages are marked as spam (with @code{$}). When I find a false
! positive, I mark the message with some other ham mark (@code{ham-marks},
! @ref{Spam ELisp Package Global Variables}). On group exit, those
! messages are copied to both groups, @samp{INBOX} (where I want to have
! the article) and @samp{training.ham} (for training bogofilter) and
! deleted from the @samp{spam.detected} folder.
The @code{gnus-article-sort-by-chars} entry simplifies detection of
false positives for me. I receive lots of worms (sweN, @dots{}), that all
--- 23267,23277 ----
Because of the @code{gnus-group-spam-classification-spam} entry, all
messages are marked as spam (with @code{$}). When I find a false
! positive, I mark the message with some other ham mark
! (@code{ham-marks}, @ref{Spam and Ham Processors}). On group exit,
! those messages are copied to both groups, @samp{INBOX} (where I want
! to have the article) and @samp{training.ham} (for training bogofilter)
! and deleted from the @samp{spam.detected} folder.
The @code{gnus-article-sort-by-chars} entry simplifies detection of
false positives for me. I receive lots of worms (sweN, @dots{}), that all
***************
*** 23323,23328 ****
--- 23307,23335 ----
not the same as on news.gmane.org, thus @code{spam-report.el} has to check
the @code{X-Report-Spam} header to find the correct number.
+ @node Spam Back Ends
+ @subsection Spam Back Ends
+ @cindex spam back ends
+
+ The spam package offers a variety of back ends for detecting spam.
+ Each back end defines a set of methods for detecting spam
+ (@pxref{Filtering Incoming Mail}, @pxref{Detecting Spam in Groups}),
+ and a pair of spam and ham processors (@pxref{Spam and Ham
+ Processors}).
+
+ @menu
+ * Blacklists and Whitelists::
+ * BBDB Whitelists::
+ * Gmane Spam Reporting::
+ * Anti-spam Hashcash Payments::
+ * Blackholes::
+ * Regular Expressions Header Matching::
+ * Bogofilter::
+ * ifile spam filtering::
+ * Spam Statistics Filtering::
+ * SpamOracle::
+ @end menu
+
@node Blacklists and Whitelists
@subsubsection Blacklists and Whitelists
@cindex spam filtering
***************
*** 23627,23632 ****
--- 23634,23648 ----
@end defvar
+ @table @kbd
+ @item M s t
+ @itemx S t
+ @kindex M s t
+ @kindex S t
+ @findex spam-bogofilter-score
+ Get the Bogofilter spamicity score (@code{spam-bogofilter-score}).
+ @end table
+
@defvar spam-use-bogofilter-headers
Set this variable if you want @code{spam-split} to use Eric Raymond's
***************
*** 23728,23747 ****
should be used. The 1.2.1 version of ifile was used to test this
functionality.
! @node spam-stat spam filtering
! @subsubsection spam-stat spam filtering
@cindex spam filtering
@cindex spam-stat, spam filtering
@cindex spam-stat
@cindex spam
! @xref{Filtering Spam Using Statistics with spam-stat}.
@defvar spam-use-stat
- Enable this variable if you want @code{spam-split} to use
- spam-stat.el, an Emacs Lisp statistical analyzer.
-
@end defvar
@defvar gnus-group-spam-exit-processor-stat
--- 23744,23764 ----
should be used. The 1.2.1 version of ifile was used to test this
functionality.
! @node Spam Statistics Filtering
! @subsubsection Spam Statistics Filtering
@cindex spam filtering
@cindex spam-stat, spam filtering
@cindex spam-stat
@cindex spam
! This back end uses the Spam Statistics Emacs Lisp package to perform
! statistics-based filtering (@pxref{Spam Statistics Package}). Before
! using this, you may want to perform some additional steps to
! initialize your Spam Statistics dictionary. @xref{Creating a
! spam-stat dictionary}.
@defvar spam-use-stat
@end defvar
@defvar gnus-group-spam-exit-processor-stat
***************
*** 23801,23818 ****
@xref{Mail Source Specifiers}, (@pxref{SpamAssassin}). This method has
the advantage that the user can see the @emph{X-Spam} headers.
! The easiest method is to make @file{spam.el} (@pxref{Filtering Spam
! Using The Spam ELisp Package}) call SpamOracle.
@vindex spam-use-spamoracle
To enable SpamOracle usage by @file{spam.el}, set the variable
@code{spam-use-spamoracle} to @code{t} and configure the
! @code{nnmail-split-fancy} or @code{nnimap-split-fancy} as described in
! the section @xref{Filtering Spam Using The Spam ELisp Package}. In
! this example the @samp{INBOX} of an nnimap server is filtered using
! SpamOracle. Mails recognized as spam mails will be moved to
! @code{spam-split-group}, @samp{Junk} in this case. Ham messages stay
! in @samp{INBOX}:
@example
(setq spam-use-spamoracle t
--- 23818,23834 ----
@xref{Mail Source Specifiers}, (@pxref{SpamAssassin}). This method has
the advantage that the user can see the @emph{X-Spam} headers.
! The easiest method is to make @file{spam.el} (@pxref{Spam Package})
! call SpamOracle.
@vindex spam-use-spamoracle
To enable SpamOracle usage by @file{spam.el}, set the variable
@code{spam-use-spamoracle} to @code{t} and configure the
! @code{nnmail-split-fancy} or @code{nnimap-split-fancy}. @xref{Spam
! Package}. In this example the @samp{INBOX} of an nnimap server is
! filtered using SpamOracle. Mails recognized as spam mails will be
! moved to @code{spam-split-group}, @samp{Junk} in this case. Ham
! messages stay in @samp{INBOX}:
@example
(setq spam-use-spamoracle t
***************
*** 23844,23857 ****
SpamOracle employs a statistical algorithm to determine whether a
message is spam or ham. In order to get good results, meaning few
! false hits or misses, SpamOracle needs training. SpamOracle learns the
! characteristics of your spam mails. Using the @emph{add} mode
(training mode) one has to feed good (ham) and spam mails to
! SpamOracle. This can be done by pressing @kbd{|} in the Summary buffer
! and pipe the mail to a SpamOracle process or using @file{spam.el}'s
! spam- and ham-processors, which is much more convenient. For a
! detailed description of spam- and ham-processors, @xref{Filtering Spam
! Using The Spam ELisp Package}.
@defvar gnus-group-spam-exit-processor-spamoracle
Add this symbol to a group's @code{spam-process} parameter by
--- 23860,23873 ----
SpamOracle employs a statistical algorithm to determine whether a
message is spam or ham. In order to get good results, meaning few
! false hits or misses, SpamOracle needs training. SpamOracle learns
! the characteristics of your spam mails. Using the @emph{add} mode
(training mode) one has to feed good (ham) and spam mails to
! SpamOracle. This can be done by pressing @kbd{|} in the Summary
! buffer and pipe the mail to a SpamOracle process or using
! @file{spam.el}'s spam- and ham-processors, which is much more
! convenient. For a detailed description of spam- and ham-processors,
! @xref{Spam Package}.
@defvar gnus-group-spam-exit-processor-spamoracle
Add this symbol to a group's @code{spam-process} parameter by
***************
*** 23900,23907 ****
processed by SpamOracle. The processor sends the messages to
SpamOracle as new samples for spam.
! @node Extending the Spam ELisp package
! @subsubsection Extending the Spam ELisp package
@cindex spam filtering
@cindex spam elisp package, extending
@cindex extending the spam elisp package
--- 23916,23923 ----
processed by SpamOracle. The processor sends the messages to
SpamOracle as new samples for spam.
! @node Extending the Spam package
! @subsection Extending the Spam package
@cindex spam filtering
@cindex spam elisp package, extending
@cindex extending the spam elisp package
***************
*** 24008,24016 ****
@end enumerate
!
! @node Filtering Spam Using Statistics with spam-stat
! @subsection Filtering Spam Using Statistics with spam-stat
@cindex Paul Graham
@cindex Graham, Paul
@cindex naive Bayesian spam filtering
--- 24024,24031 ----
@end enumerate
! @node Spam Statistics Package
! @subsection Spam Statistics Package
@cindex Paul Graham
@cindex Graham, Paul
@cindex naive Bayesian spam filtering
***************
*** 24037,24043 ****
probability of the mail being spam. If this probability is higher
than a certain threshold, the mail is considered to be spam.
! Gnus supports this kind of filtering. But it needs some setting up.
First, you need two collections of your mail, one with spam, one with
non-spam. Then you need to create a dictionary using these two
collections, and save it. And last but not least, you need to use
--- 24052,24062 ----
probability of the mail being spam. If this probability is higher
than a certain threshold, the mail is considered to be spam.
! The Spam Statistics package adds support to Gnus for this kind of
! filtering. It can be used as one of the back ends of the Spam package
! (@pxref{Spam package}), or by itself.
!
! Before using the Spam Statistics package, you need to set it up.
First, you need two collections of your mail, one with spam, one with
non-spam. Then you need to create a dictionary using these two
collections, and save it. And last but not least, you need to use
***************
*** 24123,24130 ****
@node Splitting mail using spam-stat
@subsubsection Splitting mail using spam-stat
! In order to use @code{spam-stat} to split your mail, you need to add the
! following to your @file{~/.gnus.el} file:
@lisp
(require 'spam-stat)
--- 24142,24152 ----
@node Splitting mail using spam-stat
@subsubsection Splitting mail using spam-stat
! This section describes how to use the Spam statistics
! @emph{independently} of the Spam package. @xref{Spam Package} for
! information on using it with the Spam package.
!
! First, add the following to your @file{~/.gnus.el} file:
@lisp
(require 'spam-stat)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Gnus manual update
2006-02-03 20:59 Gnus manual update Chong Yidong
@ 2006-02-06 19:18 ` Ted Zlatanov
2006-02-06 20:19 ` Chong Yidong
2006-02-06 20:25 ` message mode screwy (was: Gnus manual update) Ted Zlatanov
0 siblings, 2 replies; 30+ messages in thread
From: Ted Zlatanov @ 2006-02-06 19:18 UTC (permalink / raw)
Cc: ding
> easier to understand how the Spam package works. Unfortunately, the
> diff by itself is rather difficult to read; you may want to use ediff
> to compare, or apply the patch and read the texinfo file directly.
Hi,
I tried to apply but got some errors:
patching file gnus.texi
Hunk #1 succeeded at 814 (offset 17 lines).
Hunk #2 succeeded at 834 (offset 17 lines).
Hunk #3 FAILED at 845.
Hunk #4 succeeded at 21204 (offset 500 lines).
Hunk #5 succeeded at 22906 (offset 534 lines).
Hunk #6 FAILED at 23221.
Hunk #7 FAILED at 23329.
Hunk #8 succeeded at 23446 (offset 545 lines).
Hunk #9 FAILED at 23471.
Hunk #10 succeeded at 23732 with fuzz 2 (offset 591 lines).
Hunk #11 succeeded at 23858 (offset 591 lines).
Hunk #12 succeeded at 23898 (offset 591 lines).
Hunk #13 succeeded at 24234 (offset 600 lines).
Hunk #14 succeeded at 24396 (offset 652 lines).
Hunk #15 FAILED at 24470.
Hunk #16 FAILED at 24512.
Hunk #17 succeeded at 24566 (offset 650 lines).
Hunk #18 succeeded at 24708 (offset 684 lines).
Hunk #19 succeeded at 24736 (offset 684 lines).
Hunk #20 succeeded at 24826 (offset 684 lines).
6 out of 20 hunks FAILED -- saving rejects to file gnus.texi.rej
Can you send an updated patch please, or tell me how to fix it? I really
appreciate your work :)
Ted
Mail-Followup-To: Chong Yidong <cyd@stupidchicken.com>, ding@gnus.org
Date: Mon, 06 Feb 2006 14:18:18 -0500
In-Reply-To: <87k6ccjgzr.fsf@stupidchicken.com> (Chong Yidong's message of
"Fri, 03 Feb 2006 15:59:36 -0500")
Message-ID: <4nd5i0mh39.fsf@lifelogs.com>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Gnus manual update
2006-02-06 19:18 ` Ted Zlatanov
@ 2006-02-06 20:19 ` Chong Yidong
2006-02-06 20:31 ` spam manual update for Gnus (was: Gnus manual update) Ted Zlatanov
2006-02-06 20:25 ` message mode screwy (was: Gnus manual update) Ted Zlatanov
1 sibling, 1 reply; 30+ messages in thread
From: Chong Yidong @ 2006-02-06 20:19 UTC (permalink / raw)
Cc: ding
"Ted Zlatanov" <tzz@lifelogs.com> writes:
>> easier to understand how the Spam package works. Unfortunately, the
>> diff by itself is rather difficult to read; you may want to use ediff
>> to compare, or apply the patch and read the texinfo file directly.
> Hi,
> I tried to apply but got some errors:
> patching file gnus.texi
Here is the diff against the latest version of gnus.texi in CVS Emacs:
*** emacs/man/gnus.texi.~1.65.~ 2006-02-06 15:15:35.000000000 -0500
--- emacs/man/gnus.texi 2006-02-06 15:18:30.000000000 -0500
***************
*** 797,803 ****
* Moderation:: What to do if you're a moderator.
* Image Enhancements:: Modern versions of Emacs/XEmacs can display images.
* Fuzzy Matching:: What's the big fuzz?
! * Thwarting Email Spam:: A how-to on avoiding unsolicited commercial email.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
--- 797,804 ----
* Moderation:: What to do if you're a moderator.
* Image Enhancements:: Modern versions of Emacs/XEmacs can display images.
* Fuzzy Matching:: What's the big fuzz?
! * Thwarting Email Spam:: Simple ways to avoid unsolicited commercial email.
! * Spam Package:: A package for filtering and processing spam.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
***************
*** 826,853 ****
* Anti-Spam Basics:: Simple steps to reduce the amount of spam.
* SpamAssassin:: How to use external anti-spam tools.
* Hashcash:: Reduce spam by burning CPU time.
- * Filtering Spam Using The Spam ELisp Package::
- * Filtering Spam Using Statistics with spam-stat::
! Filtering Spam Using The Spam ELisp Package
! * Spam ELisp Package Sequence of Events::
! * Spam ELisp Package Filtering of Incoming Mail::
! * Spam ELisp Package Global Variables::
! * Spam ELisp Package Configuration Examples::
! * Blacklists and Whitelists::
! * BBDB Whitelists::
! * Gmane Spam Reporting::
! * Anti-spam Hashcash Payments::
! * Blackholes::
! * Regular Expressions Header Matching::
! * Bogofilter::
! * ifile spam filtering::
! * spam-stat spam filtering::
! * SpamOracle::
! * Extending the Spam ELisp package::
! Filtering Spam Using Statistics with spam-stat
* Creating a spam-stat dictionary::
* Splitting mail using spam-stat::
--- 827,845 ----
* Anti-Spam Basics:: Simple steps to reduce the amount of spam.
* SpamAssassin:: How to use external anti-spam tools.
* Hashcash:: Reduce spam by burning CPU time.
! Spam Package
! * Spam Package Introduction::
! * Filtering Incoming Mail::
! * Detecting Spam in Groups::
! * Spam and Ham Processors::
! * Spam Package Configuration Examples::
! * Spam Back Ends::
! * Extending the Spam package::
! * Spam Statistics Package::
! Spam Statistics Package
* Creating a spam-stat dictionary::
* Splitting mail using spam-stat::
***************
*** 20711,20717 ****
* Fetching a Group:: Starting Gnus just to read a group.
* Image Enhancements:: Modern versions of Emacs/XEmacs can display images.
* Fuzzy Matching:: What's the big fuzz?
! * Thwarting Email Spam:: A how-to on avoiding unsolicited commercial email.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
@end menu
--- 20703,20710 ----
* Fetching a Group:: Starting Gnus just to read a group.
* Image Enhancements:: Modern versions of Emacs/XEmacs can display images.
* Fuzzy Matching:: What's the big fuzz?
! * Thwarting Email Spam:: Simple ways to avoid unsolicited commercial email.
! * Spam Package:: A package for filtering and processing spam.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
@end menu
***************
*** 22378,22385 ****
* Anti-Spam Basics:: Simple steps to reduce the amount of spam.
* SpamAssassin:: How to use external anti-spam tools.
* Hashcash:: Reduce spam by burning CPU time.
- * Filtering Spam Using The Spam ELisp Package::
- * Filtering Spam Using Statistics with spam-stat::
@end menu
@node The problem of spam
--- 22371,22376 ----
***************
*** 22695,22732 ****
customized mail filtering scripts. Improvements in this area would be
a useful contribution, however.
! @node Filtering Spam Using The Spam ELisp Package
! @subsection Filtering Spam Using The Spam ELisp Package
@cindex spam filtering
@cindex spam
! The idea behind @file{spam.el} is to have a control center for spam detection
! and filtering in Gnus. To that end, @file{spam.el} does two things: it
! filters new mail, and it analyzes mail known to be spam or ham.
! @dfn{Ham} is the name used throughout @file{spam.el} to indicate
! non-spam messages.
@cindex spam-initialize
! First of all, you @strong{must} run the function
! @code{spam-initialize} to autoload @code{spam.el} and to install the
! @code{spam.el} hooks. There is one exception: if you use the
! @code{spam-use-stat} (@pxref{spam-stat spam filtering}) setting, you
! should turn it on before @code{spam-initialize}:
@example
- (setq spam-use-stat t) ;; if needed
(spam-initialize)
@end example
! So, what happens when you load @file{spam.el}?
!
! First, some hooks will get installed by @code{spam-initialize}. There
! are some hooks for @code{spam-stat} so it can save its databases, and
! there are hooks so interesting things will happen when you enter and
! leave a group. More on the sequence of events later (@pxref{Spam
! ELisp Package Sequence of Events}).
!
! You get the following keyboard commands:
@table @kbd
--- 22686,22790 ----
customized mail filtering scripts. Improvements in this area would be
a useful contribution, however.
! @node Spam Package
! @section Spam Package
@cindex spam filtering
@cindex spam
! The Spam package provides Gnus with a centralized mechanism for
! detecting and filtering spam. It filters new mail, and processes
! messages according to whether they are spam or ham. (@dfn{Ham} is the
! name used throughout this manual to indicate non-spam messages.)
!
! @menu
! * Spam Package Introduction::
! * Filtering Incoming Mail::
! * Detecting Spam in Groups::
! * Spam and Ham Processors::
! * Spam Package Configuration Examples::
! * Spam Back Ends::
! * Extending the Spam package::
! * Spam Statistics Package::
! @end menu
!
! @node Spam Package Introduction
! @subsection Spam Package Introduction
! @cindex spam filtering
! @cindex spam filtering sequence of events
! @cindex spam
!
! You must read this section to understand how the Spam package works.
! Do not skip, speed-read, or glance through this section.
@cindex spam-initialize
! @vindex spam-use-stat
! To use the Spam package, you @strong{must} first run the function
! @code{spam-initialize}:
@example
(spam-initialize)
@end example
! This autoloads @code{spam.el} and installs the various hooks necessary
! to let the Spam package do its job. In order to make use of the Spam
! package, you have to set up certain group parameters and variables,
! which we will describe below. All of the variables controlling the
! Spam package can be found in the @samp{spam} customization group.
!
! There are two ``contact points'' between the Spam package and the rest
! of Gnus: checking new mail for spam, and leaving a group.
!
! Checking new mail for spam is done in one of two ways: while splitting
! incoming mail, or when you enter a group.
!
! The first way, checking for spam while splitting incoming mail, is
! suited to mail back ends such as @code{nnml} or @code{nnimap}, where
! new mail appears in a single spool file. The Spam package processes
! incoming mail, and sends mail considered to be spam to a designated
! ``spam'' group. @xref{Filtering Incoming Mail}.
!
! The second way is suited to back ends such as @code{nntp}, which have
! no incoming mail spool, or back ends where the server is in charge of
! splitting incoming mail. In this case, when you enter a Gnus group,
! the unseen or unread messages in that group are checked for spam.
! Detected spam messages are marked as spam. @xref{Detecting Spam in
! Groups}.
!
! @cindex spam back ends
! In either case, you have to tell the Spam package what method to use
! to detect spam messages. There are several methods, or @dfn{spam back
! ends} (not to be confused with Gnus back ends!) to choose from: spam
! ``blacklists'' and ``whitelists'', dictionary-based filters, and so
! forth. @xref{Spam Back Ends}.
!
! In the Gnus summary buffer, messages that have been identified as spam
! always appear with a @samp{$} symbol.
!
! The Spam package divides Gnus groups into three categories: ham
! groups, spam groups, and unclassified groups. You should mark each of
! the groups you subscribe to as either a ham group or a spam group,
! using the @code{spam-contents} group parameter (@pxref{Group
! Parameters}). Spam groups have a special property: when you enter a
! spam group, all unseen articles are marked as spam. Thus, mail split
! into a spam group is automatically marked as spam.
!
! Identifying spam messages is only half of the Spam package's job. The
! second half comes into play whenever you exit a group buffer. At this
! point, the Spam package does several things:
!
! First, it calls @dfn{spam and ham processors} to process the articles
! according to whether they are spam or ham. There is a pair of spam
! and ham processors associated with each spam back end, and what the
! processors do depends on the back end. At present, the main role of
! spam and ham processors is for dictionary-based spam filters: they add
! the contents of the messages in the group to the filter's dictionary,
! to improve its ability to detect future spam. The @code{spam-process}
! group parameter specifies what spam processors to use. @xref{Spam and
! Ham Processors}.
!
! If the spam filter failed to mark a spam message, you can mark it
! yourself, so that the message is processed as spam when you exit the
! group:
@table @kbd
***************
*** 22737,22925 ****
@kindex S x
@kindex M s x
@findex gnus-summary-mark-as-spam
! @code{gnus-summary-mark-as-spam}.
!
! Mark current article as spam, showing it with the @samp{$} mark.
! Whenever you see a spam article, make sure to mark its summary line
! with @kbd{M-d} before leaving the group. This is done automatically
! for unread articles in @emph{spam} groups.
!
! @item M s t
! @itemx S t
! @kindex M s t
! @kindex S t
! @findex spam-bogofilter-score
! @code{spam-bogofilter-score}.
!
! You must have Bogofilter installed for that command to work properly.
!
! @xref{Bogofilter}.
!
@end table
! Also, when you load @file{spam.el}, you will be able to customize its
! variables. Try @code{customize-group} on the @samp{spam} variable
! group.
!
! @menu
! * Spam ELisp Package Sequence of Events::
! * Spam ELisp Package Filtering of Incoming Mail::
! * Spam ELisp Package Global Variables::
! * Spam ELisp Package Configuration Examples::
! * Blacklists and Whitelists::
! * BBDB Whitelists::
! * Gmane Spam Reporting::
! * Anti-spam Hashcash Payments::
! * Blackholes::
! * Regular Expressions Header Matching::
! * Bogofilter::
! * ifile spam filtering::
! * spam-stat spam filtering::
! * SpamOracle::
! * Extending the Spam ELisp package::
! @end menu
! @node Spam ELisp Package Sequence of Events
! @subsubsection Spam ELisp Package Sequence of Events
! @cindex spam filtering
! @cindex spam filtering sequence of events
! @cindex spam
! You must read this section to understand how @code{spam.el} works.
! Do not skip, speed-read, or glance through this section.
! There are two @emph{contact points}, if you will, between
! @code{spam.el} and the rest of Gnus: checking new mail for spam, and
! leaving a group.
!
! Getting new mail is done in one of two ways. You can either split
! your incoming mail or you can classify new articles as ham or spam
! when you enter the group.
!
! Splitting incoming mail is better suited to mail backends such as
! @code{nnml} or @code{nnimap} where new mail appears in a single file
! called a @dfn{Spool File}. See @xref{Spam ELisp Package Filtering of
! Incoming Mail}.
!
! For backends such as @code{nntp} there is no incoming mail spool, so
! an alternate mechanism must be used. This may also happen for
! backends where the server is in charge of splitting incoming mail, and
! Gnus does not do further splitting. The @code{spam-autodetect} and
! @code{spam-autodetect-methods} group parameters (accessible with
! @kbd{G c} and @kbd{G p} as usual), and the corresponding variables
! @code{gnus-spam-autodetect-methods} and
! @code{gnus-spam-autodetect-methods} (accessible with @kbd{M-x
! customize-variable} as usual).
!
! When @code{spam-autodetect} is used, it hooks into the process of
! entering a group. Thus, entering a group with unseen or unread
! articles becomes the substitute for checking incoming mail. Whether
! only unseen articles or all unread articles will be processed is
! determined by the @code{spam-autodetect-recheck-messages}. When set
! to @code{t}, unread messages will be rechecked.
!
! @code{spam-autodetect} grants the user at once more and less control
! of spam filtering. The user will have more control over each group's
! spam methods, so for instance the @samp{ding} group may have
! @code{spam-use-BBDB} as the autodetection method, while the
! @samp{suspect} group may have the @code{spam-use-blacklist} and
! @code{spam-use-bogofilter} methods enabled. Every article detected to
! be spam will be marked with the spam mark @samp{$} and processed on
! exit from the group as normal spam. The user has less control over
! the @emph{sequence} of checks, as he might with @code{spam-split}.
!
! When the newly split mail goes into groups, or messages are
! autodetected to be ham or spam, those groups must be exited (after
! entering, if needed) for further spam processing to happen. It
! matters whether the group is considered a ham group, a spam group, or
! is unclassified, based on its @code{spam-content} parameter
! (@pxref{Spam ELisp Package Global Variables}). Spam groups have the
! additional characteristic that, when entered, any unseen or unread
! articles (depending on the @code{spam-mark-only-unseen-as-spam}
! variable) will be marked as spam. Thus, mail split into a spam group
! gets automatically marked as spam when you enter the group.
!
! So, when you exit a group, the @code{spam-processors} are applied, if
! any are set, and the processed mail is moved to the
! @code{ham-process-destination} or the @code{spam-process-destination}
! depending on the article's classification. If the
! @code{ham-process-destination} or the @code{spam-process-destination},
! whichever is appropriate, are @code{nil}, the article is left in the
! current group.
!
! If a spam is found in any group (this can be changed to only non-spam
! groups with @code{spam-move-spam-nonspam-groups-only}), it is
! processed by the active @code{spam-processors} (@pxref{Spam ELisp
! Package Global Variables}) when the group is exited. Furthermore, the
! spam is moved to the @code{spam-process-destination} (@pxref{Spam
! ELisp Package Global Variables}) for further training or deletion.
! You have to load the @code{gnus-registry.el} package and enable the
! @code{spam-log-to-registry} variable if you want spam to be processed
! no more than once. Thus, spam is detected and processed everywhere,
! which is what most people want. If the
! @code{spam-process-destination} is @code{nil}, the spam is marked as
expired, which is usually the right thing to do.
- If spam can not be moved---because of a read-only backend such as
- @acronym{NNTP}, for example, it will be copied.
-
- If a ham mail is found in a ham group, as determined by the
- @code{ham-marks} parameter, it is processed as ham by the active ham
- @code{spam-processor} when the group is exited. With the variables
- @code{spam-process-ham-in-spam-groups} and
- @code{spam-process-ham-in-nonham-groups} the behavior can be further
- altered so ham found anywhere can be processed. You have to load the
- @code{gnus-registry.el} package and enable the
- @code{spam-log-to-registry} variable if you want ham to be processed
- no more than once. Thus, ham is detected and processed only when
- necessary, which is what most people want. More on this in
- @xref{Spam ELisp Package Configuration Examples}.
-
- If ham can not be moved---because of a read-only backend such as
- @acronym{NNTP}, for example, it will be copied.
-
If all this seems confusing, don't worry. Soon it will be as natural
as typing Lisp one-liners on a neural interface@dots{} err, sorry, that's
50 years in the future yet. Just trust us, it's not so bad.
! @node Spam ELisp Package Filtering of Incoming Mail
! @subsubsection Spam ELisp Package Filtering of Incoming Mail
@cindex spam filtering
@cindex spam filtering incoming mail
@cindex spam
! To use the @file{spam.el} facilities for incoming mail filtering, you
! must add the following to your fancy split list
! @code{nnmail-split-fancy} or @code{nnimap-split-fancy}:
@example
(: spam-split)
@end example
! Note that the fancy split may be called @code{nnmail-split-fancy} or
! @code{nnimap-split-fancy}, depending on whether you use the nnmail or
! nnimap back ends to retrieve your mail.
!
! Also, @code{spam-split} will not modify incoming mail in any way.
!
! The @code{spam-split} function will process incoming mail and send the
! mail considered to be spam into the group name given by the variable
! @code{spam-split-group}. By default that group name is @samp{spam},
! but you can customize @code{spam-split-group}. Make sure the contents
! of @code{spam-split-group} are an @emph{unqualified} group name, for
! instance in an @code{nnimap} server @samp{your-server} the value
! @samp{spam} will turn out to be @samp{nnimap+your-server:spam}. The
! value @samp{nnimap+server:spam}, therefore, is wrong and will
! actually give you the group
! @samp{nnimap+your-server:nnimap+server:spam} which may or may not
! work depending on your server's tolerance for strange group names.
!
! You can also give @code{spam-split} a parameter,
! e.g. @code{spam-use-regex-headers} or @code{"maybe-spam"}. Why is
! this useful?
! Take these split rules (with @code{spam-use-regex-headers} and
! @code{spam-use-blackholes} set):
@example
nnimap-split-fancy '(|
--- 22795,22897 ----
@kindex S x
@kindex M s x
@findex gnus-summary-mark-as-spam
! @findex gnus-summary-mark-as-spam
! Mark current article as spam, showing it with the @samp{$} mark
! (@code{gnus-summary-mark-as-spam}).
@end table
! @noindent
! Similarly, you can unmark an article if it has been erroneously marked
! as spam. @xref{Setting Marks}.
! Normally, a ham message found in a non-ham group is not processed as
! ham---the rationale is that it should be moved into a ham group for
! further processing (see below). However, you can force these articles
! to be processed as ham by setting
! @code{spam-process-ham-in-spam-groups} and
! @code{spam-process-ham-in-nonham-groups}.
! @vindex gnus-ham-process-destinations
! @vindex gnus-spam-process-destinations
! The second thing that the Spam package does when you exit a group is
! to move ham articles out of spam groups, and spam articles out of ham
! groups. Ham in a spam group is moved to the group specified by the
! variable @code{gnus-ham-process-destinations}, or the group parameter
! @code{ham-process-destination}. Spam in a ham group is moved to the
! group specified by the variable @code{gnus-spam-process-destinations},
! or the group parameter @code{spam-process-destination}. If these
! variables are not set, the articles are left in their current group.
! If an article cannot not be moved (e.g., with a read-only backend such
! as @acronym{NNTP}), it is copied.
!
! If an article is moved to another group, it is processed again when
! you visit the new group. Normally, this is not a problem, but if you
! want each article to be processed only once, load the
! @code{gnus-registry.el} package and set the variable
! @code{spam-log-to-registry} to @code{t}. @xref{Spam Package
! Configuration Examples}.
!
! Normally, spam groups ignore @code{gnus-spam-process-destinations}.
! However, if you set @code{spam-move-spam-nonspam-groups-only} to
! @code{nil}, spam will also be moved out of spam groups, depending on
! the @code{spam-process-destination} parameter.
! The final thing the Spam package does is to mark spam articles as
expired, which is usually the right thing to do.
If all this seems confusing, don't worry. Soon it will be as natural
as typing Lisp one-liners on a neural interface@dots{} err, sorry, that's
50 years in the future yet. Just trust us, it's not so bad.
! @node Filtering Incoming Mail
! @subsection Filtering Incoming Mail
@cindex spam filtering
@cindex spam filtering incoming mail
@cindex spam
! To use the Spam package to filter incoming mail, you must first set up
! fancy mail splitting. @xref{Fancy Mail Splitting}. The Spam package
! defines a special splitting function that you can add to your fancy
! split variable (either @code{nnmail-split-fancy} or
! @code{nnimap-split-fancy}, depending on your mail back end):
@example
(: spam-split)
@end example
! @vindex spam-split-group
! @noindent
! The @code{spam-split} function scans incoming mail according to your
! chosen spam back end(s), and sends messages identified as spam to a
! spam group. By default, the spam group is a group named @samp{spam},
! but you can change this by customizing @code{spam-split-group}. Make
! sure the contents of @code{spam-split-group} are an unqualified group
! name. For instance, in an @code{nnimap} server @samp{your-server},
! the value @samp{spam} means @samp{nnimap+your-server:spam}. The value
! @samp{nnimap+server:spam} is therefore wrong---it gives the group
! @samp{nnimap+your-server:nnimap+server:spam}.
!
! @code{spam-split} does not modify the contents of messages in any way.
! @vindex nnimap-split-download-body
! Note for IMAP users: if you use the @code{spam-check-bogofilter},
! @code{spam-check-ifile}, and @code{spam-check-stat} spam back ends,
! you should also set set the variable @code{nnimap-split-download-body}
! to @code{t}. These spam back ends are most useful when they can
! ``scan'' the full message body. By default, the nnimap back end only
! retrieves the message headers; @code{nnimap-split-download-body} tells
! it to retrieve the message bodies as well. We don't set this by
! default because it will slow @acronym{IMAP} down, and that is not an
! appropriate decision to make on behalf of the user. @xref{Splitting
! in IMAP}.
!
! You have to specify one or more spam back ends for @code{spam-split}
! to use, by setting the @code{spam-use-*} variables. @xref{Spam Back
! Ends}. Normally, @code{spam-split} simply uses all the spam back ends
! you enabled in this way. However, you can tell @code{spam-split} to
! use only some of them. Why this is useful? Suppose you are using the
! @code{spam-use-regex-headers} and @code{spam-use-blackholes} spam back
! ends, and the following split rule:
@example
nnimap-split-fancy '(|
***************
*** 22929,22949 ****
"mail")
@end example
! Now, the problem is that you want all ding messages to make it to the
! ding folder. But that will let obvious spam (for example, spam
! detected by SpamAssassin, and @code{spam-use-regex-headers}) through,
! when it's sent to the ding list. On the other hand, some messages to
! the ding list are from a mail server in the blackhole list, so the
! invocation of @code{spam-split} can't be before the ding rule.
!
! You can let SpamAssassin headers supersede ding rules, but all other
! @code{spam-split} rules (including a second invocation of the
! regex-headers check) will be after the ding rule:
@example
nnimap-split-fancy
'(|
! ;; @r{all spam detected by @code{spam-use-regex-headers} goes to @samp{regex-spam}}
(: spam-split "regex-spam" 'spam-use-regex-headers)
(any "ding" "ding")
;; @r{all other spam detected by spam-split goes to @code{spam-split-group}}
--- 22901,22923 ----
"mail")
@end example
! @noindent
! The problem is that you want all ding messages to make it to the ding
! folder. But that will let obvious spam (for example, spam detected by
! SpamAssassin, and @code{spam-use-regex-headers}) through, when it's
! sent to the ding list. On the other hand, some messages to the ding
! list are from a mail server in the blackhole list, so the invocation
! of @code{spam-split} can't be before the ding rule.
!
! The solution is to let SpamAssassin headers supersede ding rules, and
! perform the other @code{spam-split} rules (including a second
! invocation of the regex-headers check) after the ding rule. This is
! done by passing a parameter to @code{spam-split}:
@example
nnimap-split-fancy
'(|
! ;; @r{spam detected by @code{spam-use-regex-headers} goes to @samp{regex-spam}}
(: spam-split "regex-spam" 'spam-use-regex-headers)
(any "ding" "ding")
;; @r{all other spam detected by spam-split goes to @code{spam-split-group}}
***************
*** 22952,23009 ****
"mail")
@end example
This lets you invoke specific @code{spam-split} checks depending on
! your particular needs, and to target the results of those checks to a
particular spam group. You don't have to throw all mail into all the
spam tests. Another reason why this is nice is that messages to
mailing lists you have rules for don't have to have resource-intensive
blackhole checks performed on them. You could also specify different
spam checks for your nnmail split vs. your nnimap split. Go crazy.
! You should still have specific checks such as
! @code{spam-use-regex-headers} set to @code{t}, even if you
! specifically invoke @code{spam-split} with the check. The reason is
! that when loading @file{spam.el}, some conditional loading is done
! depending on what @code{spam-use-xyz} variables you have set. This
! is usually not critical, though.
!
! @emph{Note for IMAP users}
!
! The boolean variable @code{nnimap-split-download-body} needs to be
! set, if you want to split based on the whole message instead of just
! the headers. By default, the nnimap back end will only retrieve the
! message headers. If you use @code{spam-check-bogofilter},
! @code{spam-check-ifile}, or @code{spam-check-stat} (the splitters that
! can benefit from the full message body), you should set this variable.
! It is not set by default because it will slow @acronym{IMAP} down, and
! that is not an appropriate decision to make on behalf of the user.
!
! @xref{Splitting in IMAP}.
!
! @emph{TODO: spam.el needs to provide a uniform way of training all the
! statistical databases. Some have that functionality built-in, others
! don't.}
! @node Spam ELisp Package Global Variables
! @subsubsection Spam ELisp Package Global Variables
@cindex spam filtering
@cindex spam filtering variables
@cindex spam variables
@cindex spam
@vindex gnus-spam-process-newsgroups
! The concepts of ham processors and spam processors are very important.
! Ham processors and spam processors for a group can be set with the
! @code{spam-process} group parameter, or the
! @code{gnus-spam-process-newsgroups} variable. Ham processors take
! mail known to be non-spam (@emph{ham}) and process it in some way so
! that later similar mail will also be considered non-spam. Spam
! processors take mail known to be spam and process it so similar spam
! will be detected later.
!
! The format of the spam or ham processor entry used to be a symbol,
! but now it is a @sc{cons} cell. See the individual spam processor entries
! for more information.
@vindex gnus-spam-newsgroup-contents
Gnus learns from the spam you get. You have to collect your spam in
--- 22926,22993 ----
"mail")
@end example
+ @noindent
This lets you invoke specific @code{spam-split} checks depending on
! your particular needs, and target the results of those checks to a
particular spam group. You don't have to throw all mail into all the
spam tests. Another reason why this is nice is that messages to
mailing lists you have rules for don't have to have resource-intensive
blackhole checks performed on them. You could also specify different
spam checks for your nnmail split vs. your nnimap split. Go crazy.
! You should set the @code{spam-use-*} variables for whatever spam back
! ends you intend to use. The reason is that when loading
! @file{spam.el}, some conditional loading is done depending on what
! @code{spam-use-xyz} variables you have set. @xref{Spam Back Ends}.
!
! @c @emph{TODO: spam.el needs to provide a uniform way of training all the
! @c statistical databases. Some have that functionality built-in, others
! @c don't.}
!
! @node Detecting Spam in Groups
! @subsection Detecting Spam in Groups
!
! To detect spam when visiting a group, set the group's
! @code{spam-autodetect} and @code{spam-autodetect-methods} group
! parameters. These are accessible with @kbd{G c} or @kbd{G p}, as
! usual (@pxref{Group Parameters}).
!
! You should set the @code{spam-use-*} variables for whatever spam back
! ends you intend to use. The reason is that when loading
! @file{spam.el}, some conditional loading is done depending on what
! @code{spam-use-xyz} variables you have set.
!
! By default, only unseen articles are processed for spam. You can
! force Gnus to recheck all messages in the group by setting the
! variable @code{spam-autodetect-recheck-messages} to @code{t}.
!
! If you use the @code{spam-autodetect} method of checking for spam, you
! can specify different spam detection methods for different groups.
! For instance, the @samp{ding} group may have @code{spam-use-BBDB} as
! the autodetection method, while the @samp{suspect} group may have the
! @code{spam-use-blacklist} and @code{spam-use-bogofilter} methods
! enabled. Unlike with @code{spam-split}, you don't have any control
! over the @emph{sequence} of checks, but this is probably unimportant.
! @node Spam and Ham Processors
! @subsection Spam and Ham Processors
@cindex spam filtering
@cindex spam filtering variables
@cindex spam variables
@cindex spam
@vindex gnus-spam-process-newsgroups
! Spam and ham processors specify special actions to take when you exit
! a group buffer. Spam processors act on spam messages, and ham
! processors on ham messages. At present, the main role of these
! processors is to update the dictionaries of dictionary-based spam back
! ends such as Bogofilter (@pxref{Bogofilter}) and the Spam Statistics
! package (@pxref{Spam Statistics Filtering}).
!
! The spam and ham processors that apply to each group are determined by
! the group's@code{spam-process} group parameter. If this group
! parameter is not defined, they are determined by the variable
! @code{gnus-spam-process-newsgroups}.
@vindex gnus-spam-newsgroup-contents
Gnus learns from the spam you get. You have to collect your spam in
***************
*** 23157,23164 ****
only unseen articles or all unread articles should be checked for
spam. It is recommended that you leave it off.
! @node Spam ELisp Package Configuration Examples
! @subsubsection Spam ELisp Package Configuration Examples
@cindex spam filtering
@cindex spam filtering configuration examples
@cindex spam configuration examples
--- 23141,23148 ----
only unseen articles or all unread articles should be checked for
spam. It is recommended that you leave it off.
! @node Spam Package Configuration Examples
! @subsection Spam Package Configuration Examples
@cindex spam filtering
@cindex spam filtering configuration examples
@cindex spam configuration examples
***************
*** 23283,23293 ****
Because of the @code{gnus-group-spam-classification-spam} entry, all
messages are marked as spam (with @code{$}). When I find a false
! positive, I mark the message with some other ham mark (@code{ham-marks},
! @ref{Spam ELisp Package Global Variables}). On group exit, those
! messages are copied to both groups, @samp{INBOX} (where I want to have
! the article) and @samp{training.ham} (for training bogofilter) and
! deleted from the @samp{spam.detected} folder.
The @code{gnus-article-sort-by-chars} entry simplifies detection of
false positives for me. I receive lots of worms (sweN, @dots{}), that all
--- 23267,23277 ----
Because of the @code{gnus-group-spam-classification-spam} entry, all
messages are marked as spam (with @code{$}). When I find a false
! positive, I mark the message with some other ham mark
! (@code{ham-marks}, @ref{Spam and Ham Processors}). On group exit,
! those messages are copied to both groups, @samp{INBOX} (where I want
! to have the article) and @samp{training.ham} (for training bogofilter)
! and deleted from the @samp{spam.detected} folder.
The @code{gnus-article-sort-by-chars} entry simplifies detection of
false positives for me. I receive lots of worms (sweN, @dots{}), that all
***************
*** 23323,23328 ****
--- 23307,23335 ----
not the same as on news.gmane.org, thus @code{spam-report.el} has to check
the @code{X-Report-Spam} header to find the correct number.
+ @node Spam Back Ends
+ @subsection Spam Back Ends
+ @cindex spam back ends
+
+ The spam package offers a variety of back ends for detecting spam.
+ Each back end defines a set of methods for detecting spam
+ (@pxref{Filtering Incoming Mail}, @pxref{Detecting Spam in Groups}),
+ and a pair of spam and ham processors (@pxref{Spam and Ham
+ Processors}).
+
+ @menu
+ * Blacklists and Whitelists::
+ * BBDB Whitelists::
+ * Gmane Spam Reporting::
+ * Anti-spam Hashcash Payments::
+ * Blackholes::
+ * Regular Expressions Header Matching::
+ * Bogofilter::
+ * ifile spam filtering::
+ * Spam Statistics Filtering::
+ * SpamOracle::
+ @end menu
+
@node Blacklists and Whitelists
@subsubsection Blacklists and Whitelists
@cindex spam filtering
***************
*** 23627,23632 ****
--- 23634,23648 ----
@end defvar
+ @table @kbd
+ @item M s t
+ @itemx S t
+ @kindex M s t
+ @kindex S t
+ @findex spam-bogofilter-score
+ Get the Bogofilter spamicity score (@code{spam-bogofilter-score}).
+ @end table
+
@defvar spam-use-bogofilter-headers
Set this variable if you want @code{spam-split} to use Eric Raymond's
***************
*** 23728,23747 ****
should be used. The 1.2.1 version of ifile was used to test this
functionality.
! @node spam-stat spam filtering
! @subsubsection spam-stat spam filtering
@cindex spam filtering
@cindex spam-stat, spam filtering
@cindex spam-stat
@cindex spam
! @xref{Filtering Spam Using Statistics with spam-stat}.
@defvar spam-use-stat
- Enable this variable if you want @code{spam-split} to use
- spam-stat.el, an Emacs Lisp statistical analyzer.
-
@end defvar
@defvar gnus-group-spam-exit-processor-stat
--- 23744,23764 ----
should be used. The 1.2.1 version of ifile was used to test this
functionality.
! @node Spam Statistics Filtering
! @subsubsection Spam Statistics Filtering
@cindex spam filtering
@cindex spam-stat, spam filtering
@cindex spam-stat
@cindex spam
! This back end uses the Spam Statistics Emacs Lisp package to perform
! statistics-based filtering (@pxref{Spam Statistics Package}). Before
! using this, you may want to perform some additional steps to
! initialize your Spam Statistics dictionary. @xref{Creating a
! spam-stat dictionary}.
@defvar spam-use-stat
@end defvar
@defvar gnus-group-spam-exit-processor-stat
***************
*** 23801,23818 ****
@xref{Mail Source Specifiers}, (@pxref{SpamAssassin}). This method has
the advantage that the user can see the @emph{X-Spam} headers.
! The easiest method is to make @file{spam.el} (@pxref{Filtering Spam
! Using The Spam ELisp Package}) call SpamOracle.
@vindex spam-use-spamoracle
To enable SpamOracle usage by @file{spam.el}, set the variable
@code{spam-use-spamoracle} to @code{t} and configure the
! @code{nnmail-split-fancy} or @code{nnimap-split-fancy} as described in
! the section @xref{Filtering Spam Using The Spam ELisp Package}. In
! this example the @samp{INBOX} of an nnimap server is filtered using
! SpamOracle. Mails recognized as spam mails will be moved to
! @code{spam-split-group}, @samp{Junk} in this case. Ham messages stay
! in @samp{INBOX}:
@example
(setq spam-use-spamoracle t
--- 23818,23834 ----
@xref{Mail Source Specifiers}, (@pxref{SpamAssassin}). This method has
the advantage that the user can see the @emph{X-Spam} headers.
! The easiest method is to make @file{spam.el} (@pxref{Spam Package})
! call SpamOracle.
@vindex spam-use-spamoracle
To enable SpamOracle usage by @file{spam.el}, set the variable
@code{spam-use-spamoracle} to @code{t} and configure the
! @code{nnmail-split-fancy} or @code{nnimap-split-fancy}. @xref{Spam
! Package}. In this example the @samp{INBOX} of an nnimap server is
! filtered using SpamOracle. Mails recognized as spam mails will be
! moved to @code{spam-split-group}, @samp{Junk} in this case. Ham
! messages stay in @samp{INBOX}:
@example
(setq spam-use-spamoracle t
***************
*** 23844,23857 ****
SpamOracle employs a statistical algorithm to determine whether a
message is spam or ham. In order to get good results, meaning few
! false hits or misses, SpamOracle needs training. SpamOracle learns the
! characteristics of your spam mails. Using the @emph{add} mode
(training mode) one has to feed good (ham) and spam mails to
! SpamOracle. This can be done by pressing @kbd{|} in the Summary buffer
! and pipe the mail to a SpamOracle process or using @file{spam.el}'s
! spam- and ham-processors, which is much more convenient. For a
! detailed description of spam- and ham-processors, @xref{Filtering Spam
! Using The Spam ELisp Package}.
@defvar gnus-group-spam-exit-processor-spamoracle
Add this symbol to a group's @code{spam-process} parameter by
--- 23860,23873 ----
SpamOracle employs a statistical algorithm to determine whether a
message is spam or ham. In order to get good results, meaning few
! false hits or misses, SpamOracle needs training. SpamOracle learns
! the characteristics of your spam mails. Using the @emph{add} mode
(training mode) one has to feed good (ham) and spam mails to
! SpamOracle. This can be done by pressing @kbd{|} in the Summary
! buffer and pipe the mail to a SpamOracle process or using
! @file{spam.el}'s spam- and ham-processors, which is much more
! convenient. For a detailed description of spam- and ham-processors,
! @xref{Spam Package}.
@defvar gnus-group-spam-exit-processor-spamoracle
Add this symbol to a group's @code{spam-process} parameter by
***************
*** 23900,23907 ****
processed by SpamOracle. The processor sends the messages to
SpamOracle as new samples for spam.
! @node Extending the Spam ELisp package
! @subsubsection Extending the Spam ELisp package
@cindex spam filtering
@cindex spam elisp package, extending
@cindex extending the spam elisp package
--- 23916,23923 ----
processed by SpamOracle. The processor sends the messages to
SpamOracle as new samples for spam.
! @node Extending the Spam package
! @subsection Extending the Spam package
@cindex spam filtering
@cindex spam elisp package, extending
@cindex extending the spam elisp package
***************
*** 24008,24016 ****
@end enumerate
!
! @node Filtering Spam Using Statistics with spam-stat
! @subsection Filtering Spam Using Statistics with spam-stat
@cindex Paul Graham
@cindex Graham, Paul
@cindex naive Bayesian spam filtering
--- 24024,24031 ----
@end enumerate
! @node Spam Statistics Package
! @subsection Spam Statistics Package
@cindex Paul Graham
@cindex Graham, Paul
@cindex naive Bayesian spam filtering
***************
*** 24037,24043 ****
probability of the mail being spam. If this probability is higher
than a certain threshold, the mail is considered to be spam.
! Gnus supports this kind of filtering. But it needs some setting up.
First, you need two collections of your mail, one with spam, one with
non-spam. Then you need to create a dictionary using these two
collections, and save it. And last but not least, you need to use
--- 24052,24062 ----
probability of the mail being spam. If this probability is higher
than a certain threshold, the mail is considered to be spam.
! The Spam Statistics package adds support to Gnus for this kind of
! filtering. It can be used as one of the back ends of the Spam package
! (@pxref{Spam package}), or by itself.
!
! Before using the Spam Statistics package, you need to set it up.
First, you need two collections of your mail, one with spam, one with
non-spam. Then you need to create a dictionary using these two
collections, and save it. And last but not least, you need to use
***************
*** 24123,24130 ****
@node Splitting mail using spam-stat
@subsubsection Splitting mail using spam-stat
! In order to use @code{spam-stat} to split your mail, you need to add the
! following to your @file{~/.gnus.el} file:
@lisp
(require 'spam-stat)
--- 24142,24152 ----
@node Splitting mail using spam-stat
@subsubsection Splitting mail using spam-stat
! This section describes how to use the Spam statistics
! @emph{independently} of the Spam package. @xref{Spam Package} for
! information on using it with the Spam package.
!
! First, add the following to your @file{~/.gnus.el} file:
@lisp
(require 'spam-stat)
^ permalink raw reply [flat|nested] 30+ messages in thread
* message mode screwy (was: Gnus manual update)
2006-02-06 19:18 ` Ted Zlatanov
2006-02-06 20:19 ` Chong Yidong
@ 2006-02-06 20:25 ` Ted Zlatanov
2006-02-08 16:52 ` message mode screwy Reiner Steib
1 sibling, 1 reply; 30+ messages in thread
From: Ted Zlatanov @ 2006-02-06 20:25 UTC (permalink / raw)
On 6 Feb 2006, tzz@lifelogs.com wrote:
> Can you send an updated patch please, or tell me how to fix it? I really
> appreciate your work :)
> Ted
> Mail-Followup-To: Chong Yidong <cyd@stupidchicken.com>, ding@gnus.org
> Date: Mon, 06 Feb 2006 14:18:18 -0500
> In-Reply-To: <87k6ccjgzr.fsf@stupidchicken.com> (Chong Yidong's message of
> "Fri, 03 Feb 2006 15:59:36 -0500")
> Message-ID: <4nd5i0mh39.fsf@lifelogs.com>
> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
I get this occasionally, and my "--text follows this line" preamble
gets indented 1 space. In addition, when this happens, M-q will
format every paragraph with a hanging indent using a TAB.
Does anyone know what could be causing this?
Thanks!
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* spam manual update for Gnus (was: Gnus manual update)
2006-02-06 20:19 ` Chong Yidong
@ 2006-02-06 20:31 ` Ted Zlatanov
2006-02-06 22:49 ` spam manual update for Gnus Reiner Steib
0 siblings, 1 reply; 30+ messages in thread
From: Ted Zlatanov @ 2006-02-06 20:31 UTC (permalink / raw)
Cc: ding
On 6 Feb 2006, cyd@stupidchicken.com wrote:
> "Ted Zlatanov" <tzz@lifelogs.com> writes:
>
>>> easier to understand how the Spam package works. Unfortunately, the
>>> diff by itself is rather difficult to read; you may want to use ediff
>>> to compare, or apply the patch and read the texinfo file directly.
>> Hi,
>> I tried to apply but got some errors:
>> patching file gnus.texi
>
> Here is the diff against the latest version of gnus.texi in CVS Emacs:
I see the problem, I am using the Ding CVS, and you are using the
Emacs CVS.
What's the right approach here? I would guess we should make the
changes in both places, but start with Ding. Do you agree? Is anyone
willing to help me and Chong proofread?
If yes, let me know and I'll port the patch back over to Emacs CVS
once we're happy with the result.
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-02-06 20:31 ` spam manual update for Gnus (was: Gnus manual update) Ted Zlatanov
@ 2006-02-06 22:49 ` Reiner Steib
2006-02-08 20:20 ` Ted Zlatanov
0 siblings, 1 reply; 30+ messages in thread
From: Reiner Steib @ 2006-02-06 22:49 UTC (permalink / raw)
Cc: ding
On Mon, Feb 06 2006, Ted Zlatanov wrote:
> I see the problem, I am using the Ding CVS, and you are using the
> Emacs CVS.
Ted, if you don't want to check out Emacs CVS, you can use the v5-10
branch in Gnus' CVS.
> What's the right approach here? I would guess we should make the
> changes in both places, but start with Ding. Do you agree?
The spam.el (and spam-report.el) code differs between the Gnus CVS
trunk and the v5-10 branch (which is synced to/from Emacs CVS). I
think that in the v5-10 branch there is some inconsistency between
code and documentation, see
<http://thread.gmane.org/gmane.emacs.gnus.general/60921>. I didn't
have time to dig into it, though. (I already mentioned this in a
previous mail to Chong)
(I didn't look at the patch yet. But...) I'd guess that we should
start from v5-10/Emacs CVS and update to the new code in the trunk
later. Assuming that the next Emacs release is more close than the
next stable Gnus release.
> Is anyone willing to help me and Chong proofread?
I'd like to; but I can't promise when. But I only have practical
experience with the (quite unusual) setup described in (info
"(gnus)Spam ELisp Package Configuration Examples").
It would be good if some "ordinary users" (the less you know about the
internals, the better. ;-)) could help proofreading.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: message mode screwy
2006-02-06 20:25 ` message mode screwy (was: Gnus manual update) Ted Zlatanov
@ 2006-02-08 16:52 ` Reiner Steib
2006-02-09 15:37 ` Ted Zlatanov
0 siblings, 1 reply; 30+ messages in thread
From: Reiner Steib @ 2006-02-08 16:52 UTC (permalink / raw)
On Mon, Feb 06 2006, Ted Zlatanov wrote:
> On 6 Feb 2006, tzz@lifelogs.com wrote:
>
>> Can you send an updated patch please, or tell me how to fix it? I really
>> appreciate your work :)
>> Ted
>> Mail-Followup-To: Chong Yidong <cyd@stupidchicken.com>, ding@gnus.org
>> Date: Mon, 06 Feb 2006 14:18:18 -0500
>> In-Reply-To: <87k6ccjgzr.fsf@stupidchicken.com> (Chong Yidong's message of
>> "Fri, 03 Feb 2006 15:59:36 -0500")
>> Message-ID: <4nd5i0mh39.fsf@lifelogs.com>
>> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
>
> I get this occasionally, and my "--text follows this line" preamble
> gets indented 1 space. In addition, when this happens, M-q will
> format every paragraph with a hanging indent using a TAB.
>
> Does anyone know what could be causing this?
,----
| X-Face: bd.DQ[...]
| X-Hashcash: 1:20:060206:cyd@[...]
| X-Hashcash: 1:20:060206:ding@gnus.org::cYM3nGIyqu4Xvybe:000026TX
| --text follows this line--
| On 3 Feb 2006, cyd@stupidchicken.com wrote:
`----
I've seen similar problems when users inserted bogus headers with
extra "\n" (using `message-send-*hook'. But here, it might be the
X-Hashcash generation.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-02-06 22:49 ` spam manual update for Gnus Reiner Steib
@ 2006-02-08 20:20 ` Ted Zlatanov
2006-02-08 20:56 ` Chong Yidong
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Ted Zlatanov @ 2006-02-08 20:20 UTC (permalink / raw)
Cc: ding
On 6 Feb 2006, reinersteib+gmane@imap.cc wrote:
On Mon, Feb 06 2006, Ted Zlatanov wrote:
>
>> I see the problem, I am using the Ding CVS, and you are using the
>> Emacs CVS.
>
> Ted, if you don't want to check out Emacs CVS, you can use the v5-10
> branch in Gnus' CVS.
Oh, I didn't mean that, in fact I use the Emacs CVS a lot. I was just
out of the ding loop for a while, so I didn't know the right way to
implement changes like this. Sorry.
> The spam.el (and spam-report.el) code differs between the Gnus CVS
> trunk and the v5-10 branch (which is synced to/from Emacs CVS). I
> think that in the v5-10 branch there is some inconsistency between
> code and documentation, see
> <http://thread.gmane.org/gmane.emacs.gnus.general/60921>. I didn't
> have time to dig into it, though. (I already mentioned this in a
> previous mail to Chong)
>
> (I didn't look at the patch yet. But...) I'd guess that we should
> start from v5-10/Emacs CVS and update to the new code in the trunk
> later. Assuming that the next Emacs release is more close than the
> next stable Gnus release.
The differences are pretty major, and I would actually like to bring
the CVS version of spam.el and spam-report.el over to Emacs CVS.
There's a lot of bug fixes, but no new features and no bug reports
with the CVS version of spam.el/spam-report.el for a while now. Is
this possible?
That being said, Chong's version of the manual looks good after a
first read. I will probably suggest minor changes here and there, but
I am really glad he wrote something better than my original version :)
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-02-08 20:20 ` Ted Zlatanov
@ 2006-02-08 20:56 ` Chong Yidong
2006-02-09 15:00 ` spam.el: Bugs, compatibility with v5-10 (was: spam manual update for Gnus) Reiner Steib
2006-04-19 14:23 ` spam manual update for Gnus Reiner Steib
2 siblings, 0 replies; 30+ messages in thread
From: Chong Yidong @ 2006-02-08 20:56 UTC (permalink / raw)
Cc: Ted Zlatanov
>> (I didn't look at the patch yet. But...) I'd guess that we should
>> start from v5-10/Emacs CVS and update to the new code in the trunk
>> later. Assuming that the next Emacs release is more close than the
>> next stable Gnus release.
>
> The differences are pretty major, and I would actually like to bring
> the CVS version of spam.el and spam-report.el over to Emacs CVS.
> There's a lot of bug fixes, but no new features and no bug reports
> with the CVS version of spam.el/spam-report.el for a while now. Is
> this possible?
If the Gnus CVS version of spam.el contains just bug fixes, I think it
should definitely be checked in. (For better or worse, RMS' criteria
for releasing Emacs is not based on a freeze, but on fixing bugs :-P)
^ permalink raw reply [flat|nested] 30+ messages in thread
* spam.el: Bugs, compatibility with v5-10 (was: spam manual update for Gnus)
2006-02-08 20:20 ` Ted Zlatanov
2006-02-08 20:56 ` Chong Yidong
@ 2006-02-09 15:00 ` Reiner Steib
2006-02-13 19:04 ` spam.el: Bugs, compatibility with v5-10 Ted Zlatanov
2006-02-13 19:15 ` ham destination bugs (was: spam.el: Bugs, compatibility with v5-10) Ted Zlatanov
2006-04-19 14:23 ` spam manual update for Gnus Reiner Steib
2 siblings, 2 replies; 30+ messages in thread
From: Reiner Steib @ 2006-02-09 15:00 UTC (permalink / raw)
On Wed, Feb 08 2006, Ted Zlatanov wrote:
> The differences are pretty major, and I would actually like to bring
> the CVS version of spam.el and spam-report.el over to Emacs CVS.
You might have to restore compatibility with Emacs 20.7 if the version
in v5-10 has it. (The versions in Emacs and v5-10 should be equal.)
> There's a lot of bug fixes, but no new features and no bug reports
> with the CVS version of spam.el/spam-report.el for a while now.
[ I didn't report it yet because I wanted to test if the problem only
occurs with nnimap or also for nnml groups. But now that you ask... ]
`ham-process-destination' doesn't work correctly for me. When I find
a ham message in "Spam/Unsure", I mark it with `d'. On group exit,
the message is moved to `rs-imap-train-ham-group' but not to
`rs-imap-inbox-group'. IIRC, it worked correctly when using Gnus 5.11
(from Emacs CVS). `spam-process-destination' works also with multiple
destinations[1] for the same group.
--8<---------------cut here---------------start------------->8---
(defvar rs-imap-method "nnimap+kiz:"
"Prefered IMAP method.")
(defvar rs-imap-inbox-group (concat rs-imap-method "INBOX")
"IMAP inbox.")
(defvar rs-imap-spam-group (concat rs-imap-method "Spam/spamblock")
"Group for incoming spam.")
(defvar rs-imap-train-ham-group (concat rs-imap-method "bayes/ham")
"Group for training ham.")
(defvar rs-imap-train-spam-group (concat rs-imap-method "bayes/spam")
"Group for training spam.")
(setq
gnus-parameters
`(;; [other stuff]
(":Spam/Unsure"
(ham-process-destination ,rs-imap-train-ham-group
,rs-imap-inbox-group)
(spam-move-spam-nonspam-groups-only nil)
(spam-process-destination ,rs-imap-train-spam-group
"nnml+personal:misc.Spam.2006")
(spam-contents gnus-group-spam-classification-spam)
(auto-expire . nil))
;; [other stuff]
("^gmane\\."
(spam-contents gnus-group-spam-classification-ham);; tool bar
(spam-process
,(if (boundp 'spam-summary-exit-behavior)
;;(> (gnus-continuum-version) 5.11)
'((spam spam-use-gmane))
'(gnus-group-spam-exit-processor-report-gmane))))
;; [other stuff]
))
--8<---------------cut here---------------end--------------->8---
In the "^gmane\\." entry, I need a conditional for v5-10 and trunk,
because the backward compatibility code doesn't work correctly,
see [2].
[ Bring the trunk version of spam.el and spam-report.el over to Emacs
CVS / v5-10. ]
> Is this possible?
Additionally to those two items, my message from September [3].
Unless these problems are resolved, I'd rather not put it into v5-10.
> That being said, Chong's version of the manual looks good after a
> first read. I will probably suggest minor changes here and there, but
> I am really glad he wrote something better than my original version :)
Great!
Bye, Reiner.
[1]
,----[ *Messages* ]
| Exiting summary buffer and applying spam rules
| Registering 1 specific articles as spam using backend spam-use-move
| Copying to nnimap+kiz:bayes/spam: (657)...
| nnimap: Setting marks in bayes/spam...done
| nnimap: Updating info for nnimap+kiz:bayes/spam...done
| Copying to nnml+personal:misc.Spam.2006: (657)...
| Wrote /home/dept/ste/Mail/personal/misc.Spam.2006/715
| 1 spam messages were registered by backend spam-use-move.
| nnimap: Setting marks in Spam/Unsure...done
| Retrieving newsgroup: nnimap+kiz:bayes/spam...
`----
[2] <news:v9br2n61qd.fsf@marauder.physik.uni-ulm.de>
http://thread.gmane.org/v9br2n61qd.fsf%40marauder.physik.uni-ulm.de
[3] <news:v9vf0ugya0.fsf@marauder.physik.uni-ulm.de>
http://thread.gmane.org/v9vf0ugya0.fsf%40marauder.physik.uni-ulm.de
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: message mode screwy
2006-02-08 16:52 ` message mode screwy Reiner Steib
@ 2006-02-09 15:37 ` Ted Zlatanov
2006-02-13 18:58 ` Ted Zlatanov
0 siblings, 1 reply; 30+ messages in thread
From: Ted Zlatanov @ 2006-02-09 15:37 UTC (permalink / raw)
Cc: lrclause
On 8 Feb 2006, reinersteib+gmane@imap.cc wrote:
On Mon, Feb 06 2006, Ted Zlatanov wrote:
> On 6 Feb 2006, tzz@lifelogs.com wrote: >
>>> Can you send an updated patch please, or tell me how to fix it? I really
>>> appreciate your work :)
>>> Ted
>>> Mail-Followup-To: Chong Yidong <cyd@stupidchicken.com>, ding@gnus.org
>>> Date: Mon, 06 Feb 2006 14:18:18 -0500
>>> In-Reply-To: <87k6ccjgzr.fsf@stupidchicken.com> (Chong Yidong's message of
>>> "Fri, 03 Feb 2006 15:59:36 -0500")
>>> Message-ID: <4nd5i0mh39.fsf@lifelogs.com>
>>> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
>>
>> I get this occasionally, and my "--text follows this line" preamble
>> gets indented 1 space. In addition, when this happens, M-q will
>> format every paragraph with a hanging indent using a TAB.
>>
>> Does anyone know what could be causing this?
>
> ,----
> | X-Face: bd.DQ[...]
> | X-Hashcash: 1:20:060206:cyd@[...]
> | X-Hashcash: 1:20:060206:ding@gnus.org::cYM3nGIyqu4Xvybe:000026TX
> | --text follows this line--
> | On 3 Feb 2006, cyd@stupidchicken.com wrote:
> `----
>
> I've seen similar problems when users inserted bogus headers with
> extra "\n" (using `message-send-*hook'. But here, it might be the
> X-Hashcash generation.
Further update: I think it's trivial-cite (tc.el). I seem to get the
problem every time I get asked if ; or # (or something else) is a
cite-mark, which happens often with quoted code. Maybe it's
interaction with the X-Hashcash code, or something else in Gnus. I'm
using the latest 0.13.3. The web site mentions a trivial-cite-users
mailing list which doesn't exist at the Mailman link, so I'm not sure
how to proceed from here. Maybe Lars Clausen can help us.
Thanks
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: message mode screwy
2006-02-09 15:37 ` Ted Zlatanov
@ 2006-02-13 18:58 ` Ted Zlatanov
2006-02-13 22:15 ` Adam Sjøgren
2006-02-13 22:39 ` Reiner Steib
0 siblings, 2 replies; 30+ messages in thread
From: Ted Zlatanov @ 2006-02-13 18:58 UTC (permalink / raw)
Cc: lrclause
On 9 Feb 2006, tzz@lifelogs.com wrote:
On 8 Feb 2006, reinersteib+gmane@imap.cc wrote:
>
> On Mon, Feb 06 2006, Ted Zlatanov wrote:
>> On 6 Feb 2006, tzz@lifelogs.com wrote: >
>>>> Can you send an updated patch please, or tell me how to fix it? I really
>>>> appreciate your work :)
>>>> Ted
>>>> Mail-Followup-To: Chong Yidong <cyd@stupidchicken.com>, ding@gnus.org
>>>> Date: Mon, 06 Feb 2006 14:18:18 -0500
>>>> In-Reply-To: <87k6ccjgzr.fsf@stupidchicken.com> (Chong Yidong's message of
>>>> "Fri, 03 Feb 2006 15:59:36 -0500")
>>>> Message-ID: <4nd5i0mh39.fsf@lifelogs.com>
>>>> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
>>>
>>> I get this occasionally, and my "--text follows this line" preamble
>>> gets indented 1 space. In addition, when this happens, M-q will
>>> format every paragraph with a hanging indent using a TAB.
>>>
>>> Does anyone know what could be causing this?
>>
>> ,----
>> | X-Face: bd.DQ[...]
>> | X-Hashcash: 1:20:060206:cyd@[...]
>> | X-Hashcash: 1:20:060206:ding@gnus.org::cYM3nGIyqu4Xvybe:000026TX
>> | --text follows this line--
>> | On 3 Feb 2006, cyd@stupidchicken.com wrote:
>> `----
>>
>> I've seen similar problems when users inserted bogus headers with
>> extra "\n" (using `message-send-*hook'. But here, it might be the
>> X-Hashcash generation.
>
> Further update: I think it's trivial-cite (tc.el). I seem to get the
> problem every time I get asked if ; or # (or something else) is a
> cite-mark, which happens often with quoted code. Maybe it's
> interaction with the X-Hashcash code, or something else in Gnus. I'm
> using the latest 0.13.3. The web site mentions a trivial-cite-users
> mailing list which doesn't exist at the Mailman link, so I'm not sure
> how to proceed from here. Maybe Lars Clausen can help us.
Further further update :)
This is definitely tc.el, I haven't seen the problem unless I get
asked for the citation mark.
When I manually remove the spaces before "--text follows this line--"
and the X-Hashcash header, everything works fine. Basically, the cite
indents those two line with 1 space each and that makes message-mode
unhappy. The reason for the M-q hanging indent is that now everything
in the message is believed to be a header...
I'll look at the tc.el code, but more importantly, since Lars Clausen
hasn't reponded yet and the tc.el package seems unmaintained, can
anyone recommend a better cite mechanism for me?
Supercite, specifically, looks nice but a bit heavyweight. Any
opinions?
Thanks!
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam.el: Bugs, compatibility with v5-10
2006-02-09 15:00 ` spam.el: Bugs, compatibility with v5-10 (was: spam manual update for Gnus) Reiner Steib
@ 2006-02-13 19:04 ` Ted Zlatanov
2006-02-13 22:36 ` Emacs 20.7 compatibility in v5-10 (was: spam.el: Bugs, compatibility with v5-10) Reiner Steib
2006-02-13 19:15 ` ham destination bugs (was: spam.el: Bugs, compatibility with v5-10) Ted Zlatanov
1 sibling, 1 reply; 30+ messages in thread
From: Ted Zlatanov @ 2006-02-13 19:04 UTC (permalink / raw)
On 9 Feb 2006, reinersteib+gmane@imap.cc wrote:
On Wed, Feb 08 2006, Ted Zlatanov wrote:
>
>> The differences are pretty major, and I would actually like to bring
>> the CVS version of spam.el and spam-report.el over to Emacs CVS.
>
> You might have to restore compatibility with Emacs 20.7 if the version
> in v5-10 has it. (The versions in Emacs and v5-10 should be equal.)
I haven't broken compatibility, to my knowledge, but perhaps it's not
20.7-compatible. Is that really mandatory? It seems that, with 21
out and 22 coming, it should be less significant. If I have to, I'll
dig out an old version and get testing, I suppose.
I'll follow up separately on the problems you reported. When you
decide it's time, we'll move spam.el, no problem.
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* ham destination bugs (was: spam.el: Bugs, compatibility with v5-10)
2006-02-09 15:00 ` spam.el: Bugs, compatibility with v5-10 (was: spam manual update for Gnus) Reiner Steib
2006-02-13 19:04 ` spam.el: Bugs, compatibility with v5-10 Ted Zlatanov
@ 2006-02-13 19:15 ` Ted Zlatanov
2006-02-14 15:04 ` ham destination bugs Reiner Steib
1 sibling, 1 reply; 30+ messages in thread
From: Ted Zlatanov @ 2006-02-13 19:15 UTC (permalink / raw)
On 9 Feb 2006, reinersteib+gmane@imap.cc wrote:
On Wed, Feb 08 2006, Ted Zlatanov wrote:
> [ I didn't report it yet because I wanted to test if the problem only
> occurs with nnimap or also for nnml groups. But now that you ask... ]
> `ham-process-destination' doesn't work correctly for me. When I find
> a ham message in "Spam/Unsure", I mark it with `d'. On group exit,
> the message is moved to `rs-imap-train-ham-group' but not to
> `rs-imap-inbox-group'. IIRC, it worked correctly when using Gnus 5.11
> (from Emacs CVS). `spam-process-destination' works also with multiple
> destinations[1] for the same group.
> (defvar rs-imap-method "nnimap+kiz:"
> "Prefered IMAP method.")
> (defvar rs-imap-inbox-group (concat rs-imap-method "INBOX")
> "IMAP inbox.")
> (defvar rs-imap-spam-group (concat rs-imap-method "Spam/spamblock")
> "Group for incoming spam.")
> (defvar rs-imap-train-ham-group (concat rs-imap-method "bayes/ham")
> "Group for training ham.")
> (defvar rs-imap-train-spam-group (concat rs-imap-method "bayes/spam")
> "Group for training spam.")
>
> (setq
> gnus-parameters
> `(;; [other stuff]
> (":Spam/Unsure"
> (ham-process-destination ,rs-imap-train-ham-group
> ,rs-imap-inbox-group)
> (spam-move-spam-nonspam-groups-only nil)
> (spam-process-destination ,rs-imap-train-spam-group
> "nnml+personal:misc.Spam.2006")
> (spam-contents gnus-group-spam-classification-spam)
> (auto-expire . nil))
> ;; [other stuff]
> ("^gmane\\."
> (spam-contents gnus-group-spam-classification-ham);; tool bar
> (spam-process
> ,(if (boundp 'spam-summary-exit-behavior)
> ;;(> (gnus-continuum-version) 5.11)
> '((spam spam-use-gmane))
> '(gnus-group-spam-exit-processor-report-gmane))))
> ;; [other stuff]
> ))
Can you go inside the group and check what spam-move-ham-routine is
doing? Specifically, what is the value of
(gnus-parameter-ham-process-destination gnus-newsgroup-name)
and whether spam-move-ham-routine is getting invoked at all?
> In the "^gmane\\." entry, I need a conditional for v5-10 and trunk,
> because the backward compatibility code doesn't work correctly,
> see [2].
Well, spam-list-of-processors doesn't contain
gnus-group-spam-exit-processor-report-gmane so perhaps that's why it
doesn't work. Can you try adding
(gnus-group-spam-exit-processor-report-gmane spam spam-use-gmane)
to that list and see if that fixes your problem?
> Additionally to those two items, my message from September [3].
> Unless these problems are resolved, I'd rather not put it into v5-10.
> [3] <news:v9vf0ugya0.fsf@marauder.physik.uni-ulm.de>
> http://thread.gmane.org/v9vf0ugya0.fsf%40marauder.physik.uni-ulm.de
That message has several issues; I definitely will fix the manual by
taking Chong's version and adding the changes for the new-style
backend variables. Was there anything else I missed?
Thanks
Ted
p.s. you're so well-organized, it makes me jealous. Is there an Emacs
rs-brain-organize-mode? :)
> [1]
> ,----[ *Messages* ]
> | Exiting summary buffer and applying spam rules
> | Registering 1 specific articles as spam using backend spam-use-move
> | Copying to nnimap+kiz:bayes/spam: (657)...
> | nnimap: Setting marks in bayes/spam...done
> | nnimap: Updating info for nnimap+kiz:bayes/spam...done
> | Copying to nnml+personal:misc.Spam.2006: (657)...
> | Wrote /home/dept/ste/Mail/personal/misc.Spam.2006/715
> | 1 spam messages were registered by backend spam-use-move.
> | nnimap: Setting marks in Spam/Unsure...done
> | Retrieving newsgroup: nnimap+kiz:bayes/spam...
> `----
>
> [2] <news:v9br2n61qd.fsf@marauder.physik.uni-ulm.de>
> http://thread.gmane.org/v9br2n61qd.fsf%40marauder.physik.uni-ulm.de
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: message mode screwy
2006-02-13 18:58 ` Ted Zlatanov
@ 2006-02-13 22:15 ` Adam Sjøgren
2006-02-13 22:39 ` Reiner Steib
1 sibling, 0 replies; 30+ messages in thread
From: Adam Sjøgren @ 2006-02-13 22:15 UTC (permalink / raw)
On 13 Feb 2006 13:58:38 -0500, Ted wrote:
> I'll look at the tc.el code, but more importantly, since Lars Clausen
> hasn't reponded yet and the tc.el package seems unmaintained, can
> anyone recommend a better cite mechanism for me?
> Supercite, specifically, looks nice but a bit heavyweight. Any
> opinions?
I'm using supercite (I think I switched from tc once, perhaps because
of some differences in filling quoted text where sc did what I wanted
better than tc - it's a long time ago, though); I managed to configure
it to my liking:
(load-library "supercite")
(setq message-cite-function 'sc-cite-original)
(setq sc-citation-leader "")
(setq sc-nested-citation-p t)
; No >>>>>>> thingie:
(setq sc-reference-tag-string "")
; "On bla, bla wrote:" (this is my first and very ugly defun, so I
; won't share it):
;;(setq sc-rewrite-header-list
;; '((sc-header-on-author-wrote)))
(setq sc-preferred-header-style 0)
; Don't ask me:
(setq sc-confirm-always-p nil)
; Do not fill automatically:
(setq sc-auto-fill-region-p nil)
Just my 25 cents,
Adam
--
"Who ees thees Kählveen?" Adam Sjøgren
asjo@koldfront.dk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Emacs 20.7 compatibility in v5-10 (was: spam.el: Bugs, compatibility with v5-10)
2006-02-13 19:04 ` spam.el: Bugs, compatibility with v5-10 Ted Zlatanov
@ 2006-02-13 22:36 ` Reiner Steib
2006-03-20 19:51 ` Emacs 20.7 compatibility in v5-10 Ted Zlatanov
0 siblings, 1 reply; 30+ messages in thread
From: Reiner Steib @ 2006-02-13 22:36 UTC (permalink / raw)
On Mon, Feb 13 2006, Ted Zlatanov wrote:
> On 9 Feb 2006, reinersteib+gmane@imap.cc wrote:
>> You might have to restore compatibility with Emacs 20.7 if the version
>> in v5-10 has it. (The versions in Emacs and v5-10 should be equal.)
>
> I haven't broken compatibility, to my knowledge,
There have been some overall changes after the start of No Gnus to
remove some Emacs 20.7 compatibility stuff (e.g. point-at-{eol,bol}).
> but perhaps it's not 20.7-compatible. Is that really mandatory? It
> seems that, with 21 out and 22 coming, it should be less
> significant.
I wouldn't mind to drop Emacs 20.7 (and XEmacs 21.1) for Gnus 5.10.7
(i.e. use the same requirements as for No Gnus). If Lars agrees, I'll
happily update (info "(gnus)Emacsen") accordingly. :-)
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: message mode screwy
2006-02-13 18:58 ` Ted Zlatanov
2006-02-13 22:15 ` Adam Sjøgren
@ 2006-02-13 22:39 ` Reiner Steib
1 sibling, 0 replies; 30+ messages in thread
From: Reiner Steib @ 2006-02-13 22:39 UTC (permalink / raw)
On Mon, Feb 13 2006, Ted Zlatanov wrote:
> [...] can anyone recommend a better cite mechanism for me?
I never needed more than the Gnus builtin stuff plus a custom
`message-citation-line-function'.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ham destination bugs
2006-02-13 19:15 ` ham destination bugs (was: spam.el: Bugs, compatibility with v5-10) Ted Zlatanov
@ 2006-02-14 15:04 ` Reiner Steib
2006-02-20 14:29 ` Reiner Steib
0 siblings, 1 reply; 30+ messages in thread
From: Reiner Steib @ 2006-02-14 15:04 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]
On Mon, Feb 13 2006, Ted Zlatanov wrote:
> On 9 Feb 2006, reinersteib+gmane@imap.cc wrote:
>> (setq
>> gnus-parameters
>> `(;; [other stuff]
>> (":Spam/Unsure"
>> (ham-process-destination ,rs-imap-train-ham-group
>> ,rs-imap-inbox-group)
[ BTW: The re-indenting of code like this is a misfeature of the
citation package your are using, IMHO. ;-) ]
> Can you go inside the group and check what spam-move-ham-routine is
> doing?
For testing, I changed...
(ham-process-destination ,rs-imap-train-ham-group
,rs-imap-inbox-group)
... to...
(ham-process-destination "nnml+personal:misc.Spam.test-ham1"
"nnml+personal:misc.Spam.test-ham2")
I copied some random article to the Spam/Unsure group and marked it with
`d' (i.e. as ham). Then I quit with `q'.
Strange. I found that doesn't fail all the time. Attached you'll
find three edebug-transcripts (spam-ham.debug-662, -663, -664) from
the *Messages* buffer. In the case of spam-ham.debug-662, the article
was successfully copied to both targets. For -663 and -664 it failed.
I edebugged `spam-move-ham-routine' and `spam-copy-or-move-routine'.
> Specifically, what is the value of
>
> (gnus-parameter-ham-process-destination gnus-newsgroup-name)
M-: (gnus-parameter-ham-process-destination gnus-newsgroup-name) RET
returns ("nnimap+kiz:bayes/ham" "nnimap+kiz:INBOX").
("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
with the test setup, resp.
> and whether spam-move-ham-routine is getting invoked at all?
It is invoked.
>> In the "^gmane\\." entry, I need a conditional for v5-10 and trunk,
>> because the backward compatibility code doesn't work correctly,
>> see [2].
>
> Well, spam-list-of-processors doesn't contain
> gnus-group-spam-exit-processor-report-gmane so perhaps that's why it
> doesn't work. Can you try adding
>
> (gnus-group-spam-exit-processor-report-gmane spam spam-use-gmane)
>
> to that list and see if that fixes your problem?
I tried that some time ago without success:
http://article.gmane.org/gmane.emacs.gnus.general/60992
>> Additionally to those two items, my message from September [3].
>> Unless these problems are resolved, I'd rather not put it into v5-10.
>> [3] <news:v9vf0ugya0.fsf@marauder.physik.uni-ulm.de>
>> http://thread.gmane.org/v9vf0ugya0.fsf%40marauder.physik.uni-ulm.de
>
> That message has several issues; I definitely will fix the manual by
> taking Chong's version and adding the changes for the new-style
> backend variables. Was there anything else I missed?
I'm not aware of anything else, ATM.
> p.s. you're so well-organized, it makes me jealous. Is there an Emacs
> rs-brain-organize-mode? :)
Not really. It's a combination of Gcc-ing my articles to an nnml
group for each group/list (so I can find my own postings easily and
Gmane's find-thread (by MID) and search functions. :-)
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
[-- Attachment #2: spam-ham.debug-662 --]
[-- Type: text/plain, Size: 3477 bytes --]
No more unread articles
No more articles
Exiting summary buffer and applying spam rules
Registering 1 specific articles as ham using backend spam-use-move
Result: "nnimap+kiz:Spam/Unsure"
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: (662)
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: "nnml+personal:misc.Spam.test-ham1"
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: "nnml+personal:misc.Spam.test-ham1"
Result: nil [3 times]
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: t
Result: nil
Result: 12 (#o14, #xc, ?\C-l)
Result: "nnimap+kiz:Spam/Unsure"
Result: t
Auto-saving...done
Result: "nnimap+kiz:Spam/Unsure"
Result: (nnimap "kiz" (nnimap-address "imap.uni-ulm.de") (nnimap-directory "~/Mail/var/nnimap/kiz"))
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: nil [2 times]
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: (662)
Result: "nnml+personal:misc.Spam.test-ham1"
Result: t [2 times]
Result: (662)
Result: ham
Result: t
Result: nil [3 times]
Result: ham
Result: nil [3 times]
Result: 662 (#o1226, #x296)
Result: t
Result: nil
Result: t
Result: nil
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: 2 (#o2, #x2, ?\C-b)
Result: t [2 times]
Result: 662 (#o1226, #x296)
Result: "nnml+personal:misc.Spam.test-ham1"
Result: "Copying article 662 to group nnml+personal:misc.Spam.test-ham1"
Result: "nnml+personal:misc.Spam.test-ham1"
Copying to nnml+personal:misc.Spam.test-ham1: (662)...
Wrote ~/Mail/personal/misc.Spam.test-ham1/2
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Result: t [5 times]
Result: nil [3 times]
[ (unless copy ...) ...]
"nnml+personal:misc.Spam.test-ham1"
("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: t [3 times]
Result: (662)
Result: 662 (#o1226, #x296)
Result: t
Result: 662 (#o1226, #x296)
Result: "Deleting article 662"
Result: nil
Result: (662)
Missing SEARCH response to a SEARCH command (server not RFC compliant)...
Couldn't delete articles (662)
Result: (662) [7 times]
Result: 1 (#o1, #x1, ?\C-a)
[ Now we enter the second pass of (dolist (group groups) ...) ]
Result: (662)
Result: "nnml+personal:misc.Spam.test-ham2"
Result: t [2 times]
Result: (662)
Result: ham
Result: t
Result: nil [3 times]
Result: ham
Result: nil [3 times]
Result: 662 (#o1226, #x296)
Result: t
Result: nil
Result: t
Result: nil
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: 2 (#o2, #x2, ?\C-b)
Result: t [2 times]
Result: 662 (#o1226, #x296)
Result: "nnml+personal:misc.Spam.test-ham2"
Result: "Copying article 662 to group nnml+personal:misc.Spam.test-ham2"
Result: "nnml+personal:misc.Spam.test-ham2"
Copying to nnml+personal:misc.Spam.test-ham2: (662)...
Creating mail directory ~/Mail/personal/misc.Spam.test-ham2/
Wrote ~/Mail/personal/misc.Spam.test-ham2/1
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Result: t [5 times]
Result: nil [3 times]
Result: t [3 times]
Result: (662)
Result: 662 (#o1226, #x296)
Result: t
Result: 662 (#o1226, #x296)
Result: "Deleting article 662"
Result: nil
Result: (662)
Result: nil [5 times]
Result: (662) [2 times]
Result: 1 (#o1, #x1, ?\C-a)
Result: nil [3 times]
1 ham messages were registered by backend spam-use-move.
[-- Attachment #3: spam-ham.debug-663 --]
[-- Type: text/plain, Size: 3778 bytes --]
Copying to nnimap+kiz:Spam/Unsure: (8692)...
nnimap: Setting marks in Spam/Unsure...done
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Exiting summary buffer and applying spam rules
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Retrieving newsgroup: nnimap+kiz:Spam/Unsure...
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Fetching headers for nnimap+kiz:Spam/Unsure...done
Sorting articles...done
Generating summary...done
Marking unseen articles as spam
No more unread articles [2 times]
No more articles
Exiting summary buffer and applying spam rules
Registering 1 specific articles as ham using backend spam-use-move
Result: "nnimap+kiz:Spam/Unsure"
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: (663)
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: "nnml+personal:misc.Spam.test-ham1"
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: "nnml+personal:misc.Spam.test-ham1"
Result: nil [3 times]
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: t
Result: nil
Result: 12 (#o14, #xc, ?\C-l)
Result: "nnimap+kiz:Spam/Unsure"
Result: t
Result: "nnimap+kiz:Spam/Unsure"
Result: (nnimap "kiz" (nnimap-address "imap.uni-ulm.de") (nnimap-directory "~/Mail/var/nnimap/kiz"))
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: nil [2 times]
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: (663)
Result: "nnml+personal:misc.Spam.test-ham1"
Result: t [2 times]
Result: (663)
Result: ham
Result: t
Result: nil [3 times]
Result: ham
Result: nil [3 times]
Result: 663 (#o1227, #x297)
Result: t
Result: nil
Result: t
Result: nil
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: 2 (#o2, #x2, ?\C-b)
Result: t [2 times]
Result: 663 (#o1227, #x297)
Result: "nnml+personal:misc.Spam.test-ham1"
Result: "Copying article 663 to group nnml+personal:misc.Spam.test-ham1"
Result: "nnml+personal:misc.Spam.test-ham1"
Opening nnml server on personal...done
Copying to nnml+personal:misc.Spam.test-ham1: (663)...
Wrote ~/Mail/personal/misc.Spam.test-ham1/3
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Stop
Result: t [2 times]
Stop
Result: t [3 times]
Result: nil [3 times]
Result: t [3 times]
Result: (663)
Result: 663 (#o1227, #x297)
Result: t
Result: 663 (#o1227, #x297)
Result: "Deleting article 663"
Result: nil
Result: (663)
Result: nil [5 times]
Result: (663) [2 times]
Result: 1 (#o1, #x1, ?\C-a)
Result: (663)
Result: "nnml+personal:misc.Spam.test-ham2"
Result: t [2 times]
Result: (663)
Result: ham
Result: t
Result: nil [3 times]
Result: ham
Result: nil [3 times]
Result: 663 (#o1227, #x297)
Result: t
Result: nil
Result: t
Result: nil
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: 2 (#o2, #x2, ?\C-b)
Result: t [2 times]
Result: 663 (#o1227, #x297)
Result: "nnml+personal:misc.Spam.test-ham2"
Result: "Copying article 663 to group nnml+personal:misc.Spam.test-ham2"
Result: "nnml+personal:misc.Spam.test-ham2"
Copying to nnml+personal:misc.Spam.test-ham2: (663)...
Opened server personal using directory ~/Mail/personal
Couldn't Copy article 663: Opened server personal using directory ~/Mail/personal
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Result: t [5 times]
Result: nil [3 times]
Result: t [3 times]
Result: (663)
Result: 663 (#o1227, #x297)
Result: t
Result: 663 (#o1227, #x297)
Result: "Deleting article 663"
Result: nil
Result: (663)
Couldn't delete articles (663)
Result: (663) [7 times]
Result: 1 (#o1, #x1, ?\C-a)
Result: nil [3 times]
1 ham messages were registered by backend spam-use-move.
[-- Attachment #4: spam-ham.debug-664 --]
[-- Type: text/plain, Size: 3435 bytes --]
Generating summary...done
Marking unseen articles as spam
No more unread articles [2 times]
No more articles
Exiting summary buffer and applying spam rules
Registering 1 specific articles as ham using backend spam-use-move
Mark set [2 times]
Result: "nnimap+kiz:Spam/Unsure"
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: (664)
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: "nnml+personal:misc.Spam.test-ham1"
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: "nnml+personal:misc.Spam.test-ham1"
Result: nil [3 times]
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: t
Result: nil
Result: 12 (#o14, #xc, ?\C-l)
Result: "nnimap+kiz:Spam/Unsure"
Result: t
Result: "nnimap+kiz:Spam/Unsure"
Result: (nnimap "kiz" (nnimap-address "imap.uni-ulm.de") (nnimap-directory "~/Mail/var/nnimap/kiz"))
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: nil [2 times]
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: (664)
Result: "nnml+personal:misc.Spam.test-ham1"
Result: t [2 times]
Result: (664)
Result: ham
Result: t
Result: nil [2 times]
Mark set
Result: nil
Result: ham
Result: nil [3 times]
Result: 664 (#o1230, #x298)
Result: t
Result: nil
Result: t
Result: nil
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: 2 (#o2, #x2, ?\C-b)
Result: t [2 times]
Result: 664 (#o1230, #x298)
Result: "nnml+personal:misc.Spam.test-ham1"
Result: "Copying article 664 to group nnml+personal:misc.Spam.test-ham1"
Result: "nnml+personal:misc.Spam.test-ham1"
Opening nnml server on personal...done
Copying to nnml+personal:misc.Spam.test-ham1: (664)...
Wrote ~/Mail/personal/misc.Spam.test-ham1/4
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Result: t [5 times]
Result: nil [3 times]
Result: t [3 times]
Result: (664)
Result: 664 (#o1230, #x298)
Result: t
Result: 664 (#o1230, #x298)
Result: "Deleting article 664"
Result: nil
Result: (664)
Result: nil [5 times]
Result: (664) [2 times]
Result: 1 (#o1, #x1, ?\C-a)
Result: (664)
Result: "nnml+personal:misc.Spam.test-ham2"
Result: t [2 times]
Result: (664)
Result: ham
Result: t
Result: nil [3 times]
Result: ham
Result: nil [3 times]
Result: 664 (#o1230, #x298)
Result: t
Result: nil
Result: t
Result: nil
Result: ("nnml+personal:misc.Spam.test-ham1" "nnml+personal:misc.Spam.test-ham2")
Result: 2 (#o2, #x2, ?\C-b)
Result: t [2 times]
Result: 664 (#o1230, #x298)
Result: "nnml+personal:misc.Spam.test-ham2"
Result: "Copying article 664 to group nnml+personal:misc.Spam.test-ham2"
Result: "nnml+personal:misc.Spam.test-ham2"
mwheel-scroll: End of buffer
Copying to nnml+personal:misc.Spam.test-ham2: (664)...
Opened server personal using directory ~/Mail/personal
Couldn't Copy article 664: Opened server personal using directory ~/Mail/personal
nnimap: Updating info for nnimap+kiz:Spam/Unsure...done
Result: t [5 times]
Result: nil [3 times]
Result: t [3 times]
Result: (664)
Result: 664 (#o1230, #x298)
Result: t
Result: 664 (#o1230, #x298)
Result: "Deleting article 664"
Result: nil
Result: (664)
Couldn't delete articles (664)
Result: (664) [7 times]
Result: 1 (#o1, #x1, ?\C-a)
Result: nil [3 times]
1 ham messages were registered by backend spam-use-move.
nnimap: Setting marks in Spam/Unsure...done
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ham destination bugs
2006-02-14 15:04 ` ham destination bugs Reiner Steib
@ 2006-02-20 14:29 ` Reiner Steib
2006-05-27 10:17 ` Reiner Steib
2006-06-08 20:54 ` spam.el spam-summary-prepare-exit rewrite (was: ham destination bugs) Ted Zlatanov
0 siblings, 2 replies; 30+ messages in thread
From: Reiner Steib @ 2006-02-20 14:29 UTC (permalink / raw)
On Tue, Feb 14 2006, Reiner Steib wrote:
> (ham-process-destination ,rs-imap-train-ham-group
> ,rs-imap-inbox-group)
Another oddity using a slightly changed config (exchanged the order of
rs-imap-train-ham-group and rs-imap-inbox-group because articles in
rs-imap-train-ham-group are feed to bogofilter and get deleted
afterwards by a cron job on the IMAP server, so it's more save for me
to copy to rs-imap-inbox-group first):
(":Spam/Unsure"
(ham-process-destination ,rs-imap-inbox-group
,rs-imap-train-ham-group)
(spam-move-spam-nonspam-groups-only nil)
(spam-process-destination ,rs-imap-train-spam-group
"nnml+personal:misc.Spam.2006")
(spam-contents gnus-group-spam-classification-spam)
(auto-expire . nil))
With:
rs-imap-inbox-group = nnimap+kiz:INBOX
rs-imap-train-ham-group = nnimap+kiz:bayes/ham
rs-imap-train-spam-group = nnimap+kiz:bayes/spam
Today, I found 9 articles in Spam/Unsure. I marked 4 as ham (using
`d') and left the other 5 articles with the spam mark "$"). On group
exit, I got the following in *Message*:
--8<---------------cut here---------------start------------->8---
Exiting summary buffer and applying spam rules
Registering 5 specific articles as spam using backend spam-use-move
Copying to nnimap+kiz:bayes/spam: (679)...
nnimap: Setting marks in bayes/spam...done
nnimap: Updating info for nnimap+kiz:bayes/spam...done
Copying to nnimap+kiz:bayes/spam: (677)...
nnimap: Setting marks in bayes/spam...done
nnimap: Updating info for nnimap+kiz:bayes/spam...done
Copying to nnimap+kiz:bayes/spam: (676)...
nnimap: Setting marks in bayes/spam...done
nnimap: Updating info for nnimap+kiz:bayes/spam...done
Copying to nnimap+kiz:bayes/spam: (674)...
nnimap: Setting marks in bayes/spam...done
nnimap: Updating info for nnimap+kiz:bayes/spam...done
Copying to nnimap+kiz:bayes/spam: (672)...
nnimap: Setting marks in bayes/spam...done
nnimap: Updating info for nnimap+kiz:bayes/spam...done
Copying to nnml+personal:misc.Spam.2006: (672 674 676 677 679)...
Group misc.Fi selected
Couldn't Copy article 672: Group misc.Fi selected
Group misc.Fi selected
Couldn't Copy article 674: Group misc.Fi selected
Group misc.Fi selected
Couldn't Copy article 676: Group misc.Fi selected
Group misc.Fi selected
Couldn't Copy article 677: Group misc.Fi selected
Wrote /home/dept/ste/Mail/personal/misc.Spam.2006/828
Copying to nnml+personal:misc.Spam.2006: (677)...
Wrote /home/dept/ste/Mail/personal/misc.Spam.2006/829
Copying to nnml+personal:misc.Spam.2006: (676)...
Wrote /home/dept/ste/Mail/personal/misc.Spam.2006/830
Copying to nnml+personal:misc.Spam.2006: (674)...
Wrote /home/dept/ste/Mail/personal/misc.Spam.2006/831
Copying to nnml+personal:misc.Spam.2006: (672)...
Wrote /home/dept/ste/Mail/personal/misc.Spam.2006/832
5 spam messages were registered by backend spam-use-move.
Registering 4 specific articles as ham using backend spam-use-move
Copying to nnimap+kiz:INBOX: (678)...
nnimap: Setting marks in INBOX...done
nnimap: Updating info for nnimap+kiz:INBOX...done
Copying to nnimap+kiz:INBOX: (675)...
nnimap: Setting marks in INBOX...done
nnimap: Updating info for nnimap+kiz:INBOX...done
Copying to nnimap+kiz:INBOX: (673)...
nnimap: Setting marks in INBOX...done
nnimap: Updating info for nnimap+kiz:INBOX...done
Copying to nnimap+kiz:INBOX: (671)...
nnimap: Setting marks in INBOX...done
nnimap: Updating info for nnimap+kiz:INBOX...done
Copying to nnimap+kiz:bayes/ham: (671 673 675 678)...
Group INBOX selected
Couldn't Copy article 671: Group INBOX selected
Group INBOX selected
Couldn't Copy article 673: Group INBOX selected
Group INBOX selected
Couldn't Copy article 675: Group INBOX selected
Group INBOX selected
Couldn't Copy article 678: Group INBOX selected
nnimap: Updating info for nnimap+kiz:INBOX...done
Copying to nnimap+kiz:bayes/ham: (675)...
Group INBOX selected
Couldn't Copy article 675: Group INBOX selected
nnimap: Updating info for nnimap+kiz:INBOX...done
Copying to nnimap+kiz:bayes/ham: (673)...
Group INBOX selected
Couldn't Copy article 673: Group INBOX selected
nnimap: Updating info for nnimap+kiz:INBOX...done
Copying to nnimap+kiz:bayes/ham: (671)...
Group INBOX selected
Couldn't Copy article 671: Group INBOX selected
nnimap: Updating info for nnimap+kiz:INBOX...done
4 ham messages were registered by backend spam-use-move.
nnimap: Setting marks in Spam/Unsure...done
--8<---------------cut here---------------end--------------->8---
"misc.Fi" is a completely unrelated group on "nnml+personal" (possibly
it's the most recently created group on "nnml+personal"). I'm
puzzled.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Emacs 20.7 compatibility in v5-10
2006-02-13 22:36 ` Emacs 20.7 compatibility in v5-10 (was: spam.el: Bugs, compatibility with v5-10) Reiner Steib
@ 2006-03-20 19:51 ` Ted Zlatanov
2006-03-20 20:38 ` Reiner Steib
0 siblings, 1 reply; 30+ messages in thread
From: Ted Zlatanov @ 2006-03-20 19:51 UTC (permalink / raw)
On 13 Feb 2006, reinersteib+gmane@imap.cc wrote:
> I wouldn't mind to drop Emacs 20.7 (and XEmacs 21.1) for Gnus 5.10.7
> (i.e. use the same requirements as for No Gnus). If Lars agrees, I'll
> happily update (info "(gnus)Emacsen") accordingly. :-)
Any news on this?
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Emacs 20.7 compatibility in v5-10
2006-03-20 19:51 ` Emacs 20.7 compatibility in v5-10 Ted Zlatanov
@ 2006-03-20 20:38 ` Reiner Steib
0 siblings, 0 replies; 30+ messages in thread
From: Reiner Steib @ 2006-03-20 20:38 UTC (permalink / raw)
Cc: ding
On Mon, Mar 20 2006, Ted Zlatanov wrote:
> On 13 Feb 2006, reinersteib+gmane@imap.cc wrote:
>
>> I wouldn't mind to drop Emacs 20.7 (and XEmacs 21.1) for Gnus 5.10.7
>> (i.e. use the same requirements as for No Gnus). If Lars agrees, I'll
>> happily update (info "(gnus)Emacsen") accordingly. :-)
>
> Any news on this?
No, I didn't ask Lars upto now.
When following my suggestions WRT 5.10.8 posted today [1], it would be
sufficient to drop it starting from 5.10.9. Lars, WDYT?
Bye, Reiner.
[1] <news:v9y7z5nd3x.fsf@marauder.physik.uni-ulm.de>
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-02-08 20:20 ` Ted Zlatanov
2006-02-08 20:56 ` Chong Yidong
2006-02-09 15:00 ` spam.el: Bugs, compatibility with v5-10 (was: spam manual update for Gnus) Reiner Steib
@ 2006-04-19 14:23 ` Reiner Steib
2006-04-20 18:18 ` Ted Zlatanov
2006-04-20 18:45 ` Ted Zlatanov
2 siblings, 2 replies; 30+ messages in thread
From: Reiner Steib @ 2006-04-19 14:23 UTC (permalink / raw)
Cc: Ted Zlatanov, Chong Yidong
On Wed, Feb 08 2006, Ted Zlatanov wrote:
> The differences are pretty major, and I would actually like to bring
> the CVS version of spam.el and spam-report.el over to Emacs CVS.
> There's a lot of bug fixes, but no new features and no bug reports
> with the CVS version of spam.el/spam-report.el for a while now. Is
> this possible?
We dropped support for Emacs 20.7 and XEmacs 21.1 in v5-10 as well (as
we've done in the trunk when starting No Gnus). So technically it
should be possible to sync spam*.el to v5-10. But given that Emacs
seems to enter pretest soon and(as previously mentioned in this
thread[1]) there are some unfixed bugs in the trunk version that are
not present in v5-10, I'd suggest not to do this now.
> That being said, Chong's version of the manual looks good after a
> first read. I will probably suggest minor changes here and there, but
> I am really glad he wrote something better than my original version :)
However, as Chong's improvements to the manual are made for
Emacs/v5-10, I think we should install those in Emacs/v5-10 now. I
don't know if Ted has already made his "minor changes" based on
Chong's patch. If not, I'd suggest that Chong installs his changes in
Emacs' CVS now.
Bye, Reiner.
[1] <news:v964nakssy.fsf@marauder.physik.uni-ulm.de>
http://thread.gmane.org/gmane.emacs.gnus.general/61845/focus=61991
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-04-19 14:23 ` spam manual update for Gnus Reiner Steib
@ 2006-04-20 18:18 ` Ted Zlatanov
2006-04-20 18:38 ` Chong Yidong
2006-04-20 20:08 ` Reiner Steib
2006-04-20 18:45 ` Ted Zlatanov
1 sibling, 2 replies; 30+ messages in thread
From: Ted Zlatanov @ 2006-04-20 18:18 UTC (permalink / raw)
Cc: Chong Yidong
On 19 Apr 2006, reinersteib+gmane@imap.cc wrote:
> However, as Chong's improvements to the manual are made for
> Emacs/v5-10, I think we should install those in Emacs/v5-10 now. I
> don't know if Ted has already made his "minor changes" based on
> Chong's patch. If not, I'd suggest that Chong installs his changes in
> Emacs' CVS now.
I looked over Chong's patch. It's clean, and simplifies the flow.
I'll need to change it with the new version of spam.el, but that will
happen later in the Gnus CVS so for now it's fine to go in directly.
Let me know if you prefer to do the commit.
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-04-20 18:18 ` Ted Zlatanov
@ 2006-04-20 18:38 ` Chong Yidong
2006-04-20 20:08 ` Reiner Steib
1 sibling, 0 replies; 30+ messages in thread
From: Chong Yidong @ 2006-04-20 18:38 UTC (permalink / raw)
"Ted Zlatanov" <tzz@lifelogs.com> writes:
> On 19 Apr 2006, reinersteib+gmane@imap.cc wrote:
>
>> However, as Chong's improvements to the manual are made for
>> Emacs/v5-10, I think we should install those in Emacs/v5-10 now. I
>> don't know if Ted has already made his "minor changes" based on
>> Chong's patch. If not, I'd suggest that Chong installs his changes in
>> Emacs' CVS now.
>
> I looked over Chong's patch. It's clean, and simplifies the flow.
> I'll need to change it with the new version of spam.el, but that will
> happen later in the Gnus CVS so for now it's fine to go in directly.
>
> Let me know if you prefer to do the commit.
No, you go ahead.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-04-19 14:23 ` spam manual update for Gnus Reiner Steib
2006-04-20 18:18 ` Ted Zlatanov
@ 2006-04-20 18:45 ` Ted Zlatanov
1 sibling, 0 replies; 30+ messages in thread
From: Ted Zlatanov @ 2006-04-20 18:45 UTC (permalink / raw)
Cc: Chong Yidong
On 19 Apr 2006, reinersteib+gmane@imap.cc wrote:
> We dropped support for Emacs 20.7 and XEmacs 21.1 in v5-10 as well (as
> we've done in the trunk when starting No Gnus). So technically it
> should be possible to sync spam*.el to v5-10. But given that Emacs
> seems to enter pretest soon and(as previously mentioned in this
> thread[1]) there are some unfixed bugs in the trunk version that are
> not present in v5-10, I'd suggest not to do this now.
I'll just add it to my list of things to do after the Emacs release :)
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-04-20 18:18 ` Ted Zlatanov
2006-04-20 18:38 ` Chong Yidong
@ 2006-04-20 20:08 ` Reiner Steib
2006-04-20 23:20 ` Miles Bader
1 sibling, 1 reply; 30+ messages in thread
From: Reiner Steib @ 2006-04-20 20:08 UTC (permalink / raw)
Cc: Chong Yidong, Miles Bader
On Thu, Apr 20 2006, Ted Zlatanov wrote:
> On 19 Apr 2006, reinersteib+gmane@imap.cc wrote:
>
>> However, as Chong's improvements to the manual are made for
>> Emacs/v5-10, I think we should install those in Emacs/v5-10 now. I
>> don't know if Ted has already made his "minor changes" based on
>> Chong's patch. If not, I'd suggest that Chong installs his changes in
>> Emacs' CVS now.
>
> I looked over Chong's patch. It's clean, and simplifies the flow.
> I'll need to change it with the new version of spam.el, but that will
> happen later in the Gnus CVS so for now it's fine to go in directly.
>
> Let me know if you prefer to do the commit.
[ I guess you meant Chong here. ] Anyhow, Chong's patch still applies
cleanly, so I will install it in v5-10 and Emacs CVS now.
Thank you very much Chong and sorry for the delay.
Miles, applying the patch to Gnus trunk gives a lot of rejected
hunks[1]. I'm not sure how we should proceed with this. Ted?
Bye, Reiner.
[1] No/texi$ wc -l gnus.texi.rej
694 gnus.texi.rej
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: spam manual update for Gnus
2006-04-20 20:08 ` Reiner Steib
@ 2006-04-20 23:20 ` Miles Bader
0 siblings, 0 replies; 30+ messages in thread
From: Miles Bader @ 2006-04-20 23:20 UTC (permalink / raw)
On 4/21/06, Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> Miles, applying the patch to Gnus trunk gives a lot of rejected
> hunks[1]. I'm not sure how we should proceed with this. Ted?
I went through the conflicts, and most of them seemed fairly trivial
-- I guess minor changes in the Gnus trunk tripped up the patch, but
the text didn't seem to have changed greatly. So I just forced them
to Chong's new text.
The exceptions are that two new (in the trunk, prior to merging
Chong's changes) menu entries, and one new info node (ibid) are now
missing; somebody should re-add them wherever is appropriate in
Chong's new structure:
These are the (now missing) menu entries:
* Spam ELisp Package Sorting and Score Display in Summary Buffer::
* SpamAssassin back end::
This is the (now missing) info node:
@node Spam ELisp Package Sorting and Score Display in Summary Buffer
@subsubsection Spam ELisp Package Sorting and Score Display in Summary Buffer
@cindex spam scoring
@cindex spam sorting
@cindex spam score summary buffer
@cindex spam sort summary buffer
@cindex spam
You can display the spam score of articles in your summary buffer, and
you can sort articles by their spam score.
First you need to decide which back end you will be using. If you use
the @code{spam-use-spamassassin},
@code{spam-use-spamassassin-headers}, or @code{spam-use-regex-headers}
back end, the @code{X-Spam-Status} header will be used. If you use
@code{spam-use-bogofilter}, the @code{X-Bogosity} header will be used.
If you use @code{spam-use-crm114}, any header that matches the CRM114
score format will be used. As long as you set the appropriate back end
variable to t @emph{before} you load @file{spam.el}, you will be
fine. @code{spam.el} will automatically add the right header to the
internal Gnus list of required headers.
To show the spam score in your summary buffer, add this line to your
@code{gnus.el} file (note @code{spam.el} does not do that by default
so it won't override any existing @code{S} formats you may have).
@lisp
(defalias 'gnus-user-format-function-S 'spam-user-format-function-S)
@end lisp
Now just set your summary line format to use @code{%uS}. Here's an
example that formats the spam score in a 5-character field:
@lisp
(setq gnus-summary-line-format
"%U%R %10&user-date; $%5uS %6k %B %(%4L: %*%-25,25a%) %s \n")
@end lisp
Finally, to sort by spam status, either do it globally:
@lisp
(setq
gnus-show-threads nil
gnus-article-sort-functions
'(spam-article-sort-by-spam-status))
@end lisp
or per group (@pxref{Sorting the Summary Buffer}).
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ham destination bugs
2006-02-20 14:29 ` Reiner Steib
@ 2006-05-27 10:17 ` Reiner Steib
2006-05-30 13:55 ` Ted Zlatanov
2006-06-08 20:54 ` spam.el spam-summary-prepare-exit rewrite (was: ham destination bugs) Ted Zlatanov
1 sibling, 1 reply; 30+ messages in thread
From: Reiner Steib @ 2006-05-27 10:17 UTC (permalink / raw)
On Mon, Feb 20 2006, Reiner Steib wrote:
> On Tue, Feb 14 2006, Reiner Steib wrote:
>
>> (ham-process-destination ,rs-imap-train-ham-group
>> ,rs-imap-inbox-group)
>
> Another oddity using a slightly changed config (exchanged the order of
> rs-imap-train-ham-group and rs-imap-inbox-group because articles in
> rs-imap-train-ham-group are feed to bogofilter and get deleted
> afterwards by a cron job on the IMAP server, so it's more save for me
> to copy to rs-imap-inbox-group first):
[...]
> "misc.Fi" is a completely unrelated group on "nnml+personal" (possibly
> it's the most recently created group on "nnml+personal"). I'm
> puzzled.
I still see this (the appearance of random unrelated groups in
*Messages*). Ted, are you listening?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ham destination bugs
2006-05-27 10:17 ` Reiner Steib
@ 2006-05-30 13:55 ` Ted Zlatanov
0 siblings, 0 replies; 30+ messages in thread
From: Ted Zlatanov @ 2006-05-30 13:55 UTC (permalink / raw)
On 27 May 2006, reinersteib+gmane@imap.cc wrote:
On Mon, Feb 20 2006, Reiner Steib wrote: > On Tue, Feb 14 2006, Reiner
Steib wrote: >
>>> (ham-process-destination ,rs-imap-train-ham-group
>>> ,rs-imap-inbox-group)
>>
>> Another oddity using a slightly changed config (exchanged the order of
>> rs-imap-train-ham-group and rs-imap-inbox-group because articles in
>> rs-imap-train-ham-group are feed to bogofilter and get deleted
>> afterwards by a cron job on the IMAP server, so it's more save for me
>> to copy to rs-imap-inbox-group first):
> [...]
>> "misc.Fi" is a completely unrelated group on "nnml+personal" (possibly
>> it's the most recently created group on "nnml+personal"). I'm
>> puzzled.
>
> I still see this (the appearance of random unrelated groups in
> *Messages*). Ted, are you listening?
I am, but haven't had the time to work on this problem.
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
* spam.el spam-summary-prepare-exit rewrite (was: ham destination bugs)
2006-02-20 14:29 ` Reiner Steib
2006-05-27 10:17 ` Reiner Steib
@ 2006-06-08 20:54 ` Ted Zlatanov
1 sibling, 0 replies; 30+ messages in thread
From: Ted Zlatanov @ 2006-06-08 20:54 UTC (permalink / raw)
On 20 Feb 2006, reinersteib+gmane@imap.cc wrote:
...
> Copying to nnml+personal:misc.Spam.2006: (672 674 676 677 679)...
> Group misc.Fi selected
> Couldn't Copy article 672: Group misc.Fi selected
...
> "misc.Fi" is a completely unrelated group on "nnml+personal" (possibly
> it's the most recently created group on "nnml+personal"). I'm
> puzzled.
I think this is related to a bug I noticed and brought up a while
ago. Basically when spam.el does group-exit processing, Gnus will
refresh *every* group in some range I can't figure out, usually at
least 1 group. It's as if Gnus went and pressed M-g automatically on
a bunch of groups for no apparent reason.
I've thought about the current group-exit processing, with all the
registration/unregistration stuff, and I think I'll redo the whole
spam-summary-prepare-exit function and what depends on it. As you
know I redid the backends a while ago; I should be able to take
advantage of that and produce cleaner code with fewer bugs.
If anyone is interested in helping or suggesting changes, now is the
time to speak up.
Ted
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2006-06-08 20:54 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-03 20:59 Gnus manual update Chong Yidong
2006-02-06 19:18 ` Ted Zlatanov
2006-02-06 20:19 ` Chong Yidong
2006-02-06 20:31 ` spam manual update for Gnus (was: Gnus manual update) Ted Zlatanov
2006-02-06 22:49 ` spam manual update for Gnus Reiner Steib
2006-02-08 20:20 ` Ted Zlatanov
2006-02-08 20:56 ` Chong Yidong
2006-02-09 15:00 ` spam.el: Bugs, compatibility with v5-10 (was: spam manual update for Gnus) Reiner Steib
2006-02-13 19:04 ` spam.el: Bugs, compatibility with v5-10 Ted Zlatanov
2006-02-13 22:36 ` Emacs 20.7 compatibility in v5-10 (was: spam.el: Bugs, compatibility with v5-10) Reiner Steib
2006-03-20 19:51 ` Emacs 20.7 compatibility in v5-10 Ted Zlatanov
2006-03-20 20:38 ` Reiner Steib
2006-02-13 19:15 ` ham destination bugs (was: spam.el: Bugs, compatibility with v5-10) Ted Zlatanov
2006-02-14 15:04 ` ham destination bugs Reiner Steib
2006-02-20 14:29 ` Reiner Steib
2006-05-27 10:17 ` Reiner Steib
2006-05-30 13:55 ` Ted Zlatanov
2006-06-08 20:54 ` spam.el spam-summary-prepare-exit rewrite (was: ham destination bugs) Ted Zlatanov
2006-04-19 14:23 ` spam manual update for Gnus Reiner Steib
2006-04-20 18:18 ` Ted Zlatanov
2006-04-20 18:38 ` Chong Yidong
2006-04-20 20:08 ` Reiner Steib
2006-04-20 23:20 ` Miles Bader
2006-04-20 18:45 ` Ted Zlatanov
2006-02-06 20:25 ` message mode screwy (was: Gnus manual update) Ted Zlatanov
2006-02-08 16:52 ` message mode screwy Reiner Steib
2006-02-09 15:37 ` Ted Zlatanov
2006-02-13 18:58 ` Ted Zlatanov
2006-02-13 22:15 ` Adam Sjøgren
2006-02-13 22:39 ` Reiner Steib
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).