* How to use the spam.el package? @ 2003-11-01 20:17 Kai Grossjohann 2003-11-03 18:37 ` Ted Zlatanov 2003-11-03 20:15 ` Kai Grossjohann 0 siblings, 2 replies; 11+ messages in thread From: Kai Grossjohann @ 2003-11-01 20:17 UTC (permalink / raw) I tried several times to configure spam.el for my use. Finally, I came up with the outside-Gnus setup that I want to use, and so I gave spam.el another go. I'm sending this here to ask whether my configuration looks sane and to report some findings where the documentation was confusing. My configuration looks like this: ;; Spam (setq spam-use-bogofilter-headers t) (setq spam-split-group "INBOX.spam") (setq spam-junk-mailgroups (list "nnimap:INBOX.spam" "nnimap:INBOX.makespam")) (setq gnus-spam-process-newsgroups '(("^nnimap:INBOX" nil))) (setq gnus-spam-process-destinations '(("^nnimap:INBOX" "nnimap:INBOX.makespam"))) (spam-initialize) ;; and then: (setq nnimap-split-fancy '(| (: spam-split) ... "INBOX.misc")) I'm reading mail from a Cyrus server with the following setup: Incoming messages are passed through bogofilter before Cyrus sees them. There is a cron job which goes through all INBOX.makespam and INBOX.makeham folders for all users and classifies messages found there as spam or ham respectively. So what I want is this: Incoming spam should be split into nnimap:INBOX.spam. Hitting M-d on a message should send it to the nnimap:INBOX.makespam group, where it will be picked up by the Cron job later. Also, marking something as ham in a spam group should result in that message being moved to nnimap:INBOX, I guess. (There, nnimap-split-fancy will find it again, and then hopefully won't consider it spam again.) Things I found: * The docs say "First of all, you *must* run the function `spam-initialize' to autoload `spam.el' and to install the `spam.el' hooks". In fact, however, it seems that spam-initialize should come /last/, not first: its behavior depends on the other variables being set. I like obscure jokes just as well as the next person, but maybe a hint for the uninitiated would be nice? * I /think/ that spam-split-group should be a naked group name whereas all the other variables should be fully qualified group names. It isn't made clear in the documentation. * The format of gnus-spam-process-newsgroups and gnus-spam-process-destinations isn't made clear, neither in info nor in C-h v. I suggest to say something like "this should be a list of newsgroup specifications. Each newsgroup specification has the format (REGEXP PROCESSOR)". I found out what to do by running M-x customize-variable RET and then looking at the resulting Lisp expression, but why not make it explicit? * I wasn't sure that just setting the processor to nil was the right thing to do, I was just operating on a hunch that it might work. How about making this explicit, too? * I would also appreciate some tutorial kind of advice, like saying for the following common situation, this is how you set the variables. It's difficult to figure out how it all ties together: you have to read all of the main node on spam.el and /understand/ it, too, if you want to configure things. I guess there are numerous mistakes in my config, but for the time being it works, and the smoke coming from my head is making the room foggy. * How do I tell spam.el that messages from nnimap:INBOX.spam and nnimap:INBOX.makespam don't need to be frobbed further? I'm afraid they'll be subjected to gnus-spam-process-destinations... * I completely ignored the group parameters thing, even though it seemed the easiest way to configure stuff. The reason for doing so was that I didn't fancy setting the same spam process destination on all my groups. (I just switched to a new server and haven't switched on topics mode, yet.) I hope that the above stupid questions are useful for something. I'd like to promise to help improving the documentation, but what with real life and a job, my time has been more limited than some months ago. Now let me go talk to the Bogofilter folks about setting up the server-side splitting thing. Kai ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-01 20:17 How to use the spam.el package? Kai Grossjohann @ 2003-11-03 18:37 ` Ted Zlatanov 2003-11-03 20:26 ` Kai Grossjohann 2003-11-03 20:15 ` Kai Grossjohann 1 sibling, 1 reply; 11+ messages in thread From: Ted Zlatanov @ 2003-11-03 18:37 UTC (permalink / raw) Cc: ding On Sat, 01 Nov 2003, kai@emptydomain.de wrote: > (setq spam-use-bogofilter-headers t) > (setq spam-split-group "INBOX.spam") > (setq spam-junk-mailgroups (list "nnimap:INBOX.spam" "nnimap:INBOX.makespam")) > (setq gnus-spam-process-newsgroups > '(("^nnimap:INBOX" nil))) > (setq gnus-spam-process-destinations > '(("^nnimap:INBOX" "nnimap:INBOX.makespam"))) > (spam-initialize) You don't need to explicitly define the spam-process parameter - it's nil by default, as one would expect. Everything else looks fine. > I'm reading mail from a Cyrus server with the following setup: > Incoming messages are passed through bogofilter before Cyrus sees > them. There is a cron job which goes through all INBOX.makespam and > INBOX.makeham folders for all users and classifies messages found > there as spam or ham respectively. Great. > So what I want is this: Incoming spam should be split into > nnimap:INBOX.spam. Hitting M-d on a message should send it to the > nnimap:INBOX.makespam group, where it will be picked up by the Cron > job later. Also, marking something as ham in a spam group should > result in that message being moved to nnimap:INBOX, I guess. > (There, nnimap-split-fancy will find it again, and then hopefully > won't consider it spam again.) That's sensible. Just don't try to split spam from INBOX right back into INBOX - that can cause problems. > Things I found: > > * The docs say "First of all, you *must* run the function > `spam-initialize' to autoload `spam.el' and to install the > `spam.el' hooks". In fact, however, it seems that spam-initialize > should come /last/, not first: its behavior depends on the other > variables being set. > > I like obscure jokes just as well as the next person, but maybe a > hint for the uninitiated would be nice? The docs are correct. The behavior of spam-initialize will not be affected by any spam.el variables, except for spam-use-stat which adds some hooks (the spam-use-stat exception should probably be in the manual). > * I /think/ that spam-split-group should be a naked group name > whereas all the other variables should be fully qualified group > names. It isn't made clear in the documentation. You are correct. I have clarified it. > * The format of gnus-spam-process-newsgroups and > gnus-spam-process-destinations isn't made clear, neither in info > nor in C-h v. I suggest to say something like "this should be a > list of newsgroup specifications. Each newsgroup specification > has the format (REGEXP PROCESSOR)". > I found out what to do by running M-x customize-variable RET and > then looking at the resulting Lisp expression, but why not make it > explicit? I have added this clarification. I strongly prefer that users use the customize interface, so I don't want to provide code samples for setting the variables manually. If you do, please write them and add them to the manual. I have no problem with that. > * I wasn't sure that just setting the processor to nil was the right > thing to do, I was just operating on a hunch that it might work. > How about making this explicit, too? Why? It makes perfect sense that if you don't explicitly set a processor, there won't be one. I don't want to confuse the users more than they need to be :) > * I would also appreciate some tutorial kind of advice, like saying > for the following common situation, this is how you set the > variables. It's difficult to figure out how it all ties together: > you have to read all of the main node on spam.el and /understand/ > it, too, if you want to configure things. Sure. I welcome any contributions in that direction. Integration of spam.el with the registry plus making the registry work properly in all cases are higher on my priority list. > * How do I tell spam.el that messages from nnimap:INBOX.spam and > nnimap:INBOX.makespam don't need to be frobbed further? I'm > afraid they'll be subjected to gnus-spam-process-destinations... If the messages in those groups are marked as spam, they will be moved to the spam-process-destination whether there is or isn't a spam processor. So don't set a spam-process-destination if you don't want one, ditto for the spam-processor. Is that what you're asking? > * I completely ignored the group parameters thing, even though it > seemed the easiest way to configure stuff. The reason for doing > so was that I didn't fancy setting the same spam process > destination on all my groups. (I just switched to a new server > and haven't switched on topics mode, yet.) Yeah, unfortunately group/topic parameters are incredibly easy and convenient for this task, so I'd rather have the user use that than write Lisp code. > I hope that the above stupid questions are useful for something. > I'd like to promise to help improving the documentation, but what > with real life and a job, my time has been more limited than some > months ago. No problem, I appreciate the suggestions. Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-03 18:37 ` Ted Zlatanov @ 2003-11-03 20:26 ` Kai Grossjohann 2003-11-03 21:20 ` Ted Zlatanov 0 siblings, 1 reply; 11+ messages in thread From: Kai Grossjohann @ 2003-11-03 20:26 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > On Sat, 01 Nov 2003, kai@emptydomain.de wrote: >> (setq spam-use-bogofilter-headers t) >> (setq spam-split-group "INBOX.spam") >> (setq spam-junk-mailgroups (list "nnimap:INBOX.spam" "nnimap:INBOX.makespam")) >> (setq gnus-spam-process-newsgroups >> '(("^nnimap:INBOX" nil))) >> (setq gnus-spam-process-destinations >> '(("^nnimap:INBOX" "nnimap:INBOX.makespam"))) >> (spam-initialize) > > You don't need to explicitly define the spam-process parameter - it's > nil by default, as one would expect. Everything else looks fine. Errm, you mean gnus-spam-process-newsgroups? Okay, so I can take that out, I guess. >> I'm reading mail from a Cyrus server with the following setup: >> Incoming messages are passed through bogofilter before Cyrus sees >> them. There is a cron job which goes through all INBOX.makespam and >> INBOX.makeham folders for all users and classifies messages found >> there as spam or ham respectively. > > Great. Heh, I'm somewhat self-satisfied with having achieved this setup. Goes to show you how much I've been out of touch with doing any real work... I even had to ask folks in a (German) newsgroup about the shell and perl scripts I use for Bogofilter training... >> So what I want is this: Incoming spam should be split into >> nnimap:INBOX.spam. Hitting M-d on a message should send it to the >> nnimap:INBOX.makespam group, where it will be picked up by the Cron >> job later. Also, marking something as ham in a spam group should >> result in that message being moved to nnimap:INBOX, I guess. >> (There, nnimap-split-fancy will find it again, and then hopefully >> won't consider it spam again.) > > That's sensible. Just don't try to split spam from INBOX right back > into INBOX - that can cause problems. I must have done a mistake: I tried to tell Bogofilter that messages in INBOX.makeham aren't spam, then put them back in INBOX. Then they were split again as spam. Oh, wait! Stupid me: I should be deleting the X-Bogosity header from messages that were made ham. Gnahh :-/ *bangs head against wall* >> Things I found: >> >> * The docs say "First of all, you *must* run the function >> `spam-initialize' to autoload `spam.el' and to install the >> `spam.el' hooks". In fact, however, it seems that spam-initialize >> should come /last/, not first: its behavior depends on the other >> variables being set. >> >> I like obscure jokes just as well as the next person, but maybe a >> hint for the uninitiated would be nice? > > The docs are correct. The behavior of spam-initialize will not be > affected by any spam.el variables, except for spam-use-stat which adds > some hooks (the spam-use-stat exception should probably be in the > manual). Hm. Ooops. But what about spam-install-hooks? That seems to be set to something depending on spam-use-foo upon loading spam.el, so if I call spam-initialize first, then frob spam-use-foo, then it's too late. So I'll also have to set spam-install-hooks, right? [time passes] D'oh. spam-install-hooks just arranges for spam-initialize to be called, which it was already. So no harm done. *blush* >> * I /think/ that spam-split-group should be a naked group name >> whereas all the other variables should be fully qualified group >> names. It isn't made clear in the documentation. > > You are correct. I have clarified it. At least one observation in this message that wasn't wrong. >> * The format of gnus-spam-process-newsgroups and >> gnus-spam-process-destinations isn't made clear, neither in info >> nor in C-h v. I suggest to say something like "this should be a >> list of newsgroup specifications. Each newsgroup specification >> has the format (REGEXP PROCESSOR)". > >> I found out what to do by running M-x customize-variable RET and >> then looking at the resulting Lisp expression, but why not make it >> explicit? > > I have added this clarification. I strongly prefer that users use the > customize interface, so I don't want to provide code samples for > setting the variables manually. If you do, please write them and add > them to the manual. I have no problem with that. Okay. >> * I wasn't sure that just setting the processor to nil was the right >> thing to do, I was just operating on a hunch that it might work. >> How about making this explicit, too? > > Why? It makes perfect sense that if you don't explicitly set a > processor, there won't be one. I don't want to confuse the users > more than they need to be :) Well, spam is being processed by Bogofilter in my case. Or, put another way, the processing I do on spam is to move it to INBOX.spam. Maybe I'm just being too stupid. >> * I would also appreciate some tutorial kind of advice, like saying >> for the following common situation, this is how you set the >> variables. It's difficult to figure out how it all ties together: >> you have to read all of the main node on spam.el and /understand/ >> it, too, if you want to configure things. > > Sure. I welcome any contributions in that direction. Integration of > spam.el with the registry plus making the registry work properly in > all cases are higher on my priority list. Ah, yes, I should have expected the please-do-it answer ;-) Sorry that I didn't just do it in the first place, but came here whining instead. >> * How do I tell spam.el that messages from nnimap:INBOX.spam and >> nnimap:INBOX.makespam don't need to be frobbed further? I'm >> afraid they'll be subjected to gnus-spam-process-destinations... > > If the messages in those groups are marked as spam, they will be > moved to the spam-process-destination whether there is or isn't a > spam processor. So don't set a spam-process-destination if you don't > want one, ditto for the spam-processor. Is that what you're asking? I want spam to be moved to INBOX.spam. But it doesn't make sense (IMHO) to move messages from INBOX.spam to INBOX.spam. I see an infloop lurking there. But it turns out that I haven't experienced that infloop yet. Soooo, there must be something (yet again) I'm missing. >> * I completely ignored the group parameters thing, even though it >> seemed the easiest way to configure stuff. The reason for doing >> so was that I didn't fancy setting the same spam process >> destination on all my groups. (I just switched to a new server >> and haven't switched on topics mode, yet.) > > Yeah, unfortunately group/topic parameters are incredibly easy and > convenient for this task, so I'd rather have the user use that than > write Lisp code. ;-) Kai ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-03 20:26 ` Kai Grossjohann @ 2003-11-03 21:20 ` Ted Zlatanov 2003-11-03 22:06 ` Kai Grossjohann 2003-11-04 21:39 ` Kai Grossjohann 0 siblings, 2 replies; 11+ messages in thread From: Ted Zlatanov @ 2003-11-03 21:20 UTC (permalink / raw) Cc: ding On Mon, 03 Nov 2003, kai@emptydomain.de wrote: > Hm. Ooops. But what about spam-install-hooks? That seems to be > set to something depending on spam-use-foo upon loading spam.el, so > if I call spam-initialize first, then frob spam-use-foo, then it's > too late. So I'll also have to set spam-install-hooks, right? You used to have to do it. The new way is to just call the autoloaded spam-initialize, which will (we hope) do everything properly, and if it doesn't it will be fixed. > *blush* It's really OK to have these questions - as you can see, you've already pointed out several problems or unclear spots in the docs. >>> * I wasn't sure that just setting the processor to nil was the >>> right thing to do, I was just operating on a hunch that it might >>> work. How about making this explicit, too? >> >> Why? It makes perfect sense that if you don't explicitly set a >> processor, there won't be one. I don't want to confuse the users >> more than they need to be :) > > Well, spam is being processed by Bogofilter in my case. Or, put > another way, the processing I do on spam is to move it to > INBOX.spam. OK, how would you suggest I change the docs and/or implementation? I understand the problem, I'm just not sure how I can fix it. >>> * I would also appreciate some tutorial kind of advice, like >>> saying for the following common situation, this is how you set >>> the variables. It's difficult to figure out how it all ties >>> together: you have to read all of the main node on spam.el and >>> /understand/ it, too, if you want to configure things. >> >> Sure. I welcome any contributions in that direction. Integration >> of spam.el with the registry plus making the registry work properly >> in all cases are higher on my priority list. > > Ah, yes, I should have expected the please-do-it answer ;-) > Sorry that I didn't just do it in the first place, but came here > whining instead. You misunderstood, I'm not opposed to writing the tutorials myself, and in fact I probably will if no one else does. I just want to finish what I consider essential functionality first, in time for the new Gnus release I hope. >>> * How do I tell spam.el that messages from nnimap:INBOX.spam and >>> nnimap:INBOX.makespam don't need to be frobbed further? I'm >>> afraid they'll be subjected to gnus-spam-process-destinations... >> >> If the messages in those groups are marked as spam, they will be >> moved to the spam-process-destination whether there is or isn't a >> spam processor. So don't set a spam-process-destination if you >> don't want one, ditto for the spam-processor. Is that what you're >> asking? > > I want spam to be moved to INBOX.spam. But it doesn't make sense > (IMHO) to move messages from INBOX.spam to INBOX.spam. I see an > infloop lurking there. Nah, we move message by unique article number, not message ID. The new articles that were just moved in are not automatically integrated in the loop, so it will end when the old articles are all moved. It should work. I wouldn't recommend it, but for pure obfuscated fun it's hard to beat it. Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-03 21:20 ` Ted Zlatanov @ 2003-11-03 22:06 ` Kai Grossjohann 2003-11-04 2:36 ` Ted Zlatanov 2003-11-04 21:39 ` Kai Grossjohann 1 sibling, 1 reply; 11+ messages in thread From: Kai Grossjohann @ 2003-11-03 22:06 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > On Mon, 03 Nov 2003, kai@emptydomain.de wrote: >> >> I want spam to be moved to INBOX.spam. But it doesn't make sense >> (IMHO) to move messages from INBOX.spam to INBOX.spam. I see an >> infloop lurking there. > > Nah, we move message by unique article number, not message ID. The > new articles that were just moved in are not automatically integrated > in the loop, so it will end when the old articles are all moved. It > should work. I wouldn't recommend it, but for pure obfuscated fun > it's hard to beat it. Okay. So, it's better to avoid it. Recall that I have gnus-spam-process-destinations set to (("^nnimap:" "nnimap:INBOX.makespam")). (Made a mistake makespam vs spam there.) So how do I tell spam.el NOT to apply this rule to the nnimap:INBOX.makespam group? Formulating a regexp that matches everything that "^nnimap:" matches, except "nnimap:INBOX.makespam", is difficult. Hm. Maybe I could set a group parameter on nnimap:INBOX.makespam that overrides the value with nil? Or I could put in two entries: (("^nnimap:INBOX.makespam$" nil) ("^nnimap:" "nnimap:INBOX.makespam")) If it searches the alist from the beginning and uses the first match, then it would work. It's getting a bit complicated. I'm sure the reason is that I'm doing something wrong. I stumbled across this thing within five minutes; everybody must be having the same issue. Except, of course, if they take another path where there is no stumbling block. Do people put all ham groups in one topic and all spam groups in another, then use topic parameters on those two topics, to avoid this problem? Kai ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-03 22:06 ` Kai Grossjohann @ 2003-11-04 2:36 ` Ted Zlatanov 0 siblings, 0 replies; 11+ messages in thread From: Ted Zlatanov @ 2003-11-04 2:36 UTC (permalink / raw) Cc: ding On Mon, 03 Nov 2003, kai@emptydomain.de wrote: >> Nah, we move message by unique article number, not message ID. The >> new articles that were just moved in are not automatically >> integrated in the loop, so it will end when the old articles are >> all moved. It should work. I wouldn't recommend it, but for pure >> obfuscated fun it's hard to beat it. > > Okay. So, it's better to avoid it. Recall that I have > gnus-spam-process-destinations set to (("^nnimap:" > "nnimap:INBOX.makespam")). (Made a mistake makespam vs spam there.) > > So how do I tell spam.el NOT to apply this rule to the > nnimap:INBOX.makespam group? Formulating a regexp that matches > everything that "^nnimap:" matches, except "nnimap:INBOX.makespam", > is difficult. > > Hm. Maybe I could set a group parameter on nnimap:INBOX.makespam > that overrides the value with nil? That's what I do. I also have ham/spam topics, and some of my settings are different depending on the backend server. > Or I could put in two entries: > > (("^nnimap:INBOX.makespam$" nil) > ("^nnimap:" "nnimap:INBOX.makespam")) > > If it searches the alist from the beginning and uses the first > match, then it would work. I would guess it searches from the beginning, it's a standard Elisp alist. > It's getting a bit complicated. I'm sure the reason is that I'm > doing something wrong. I stumbled across this thing within five > minutes; everybody must be having the same issue. Except, of > course, if they take another path where there is no stumbling block. > > Do people put all ham groups in one topic and all spam groups in > another, then use topic parameters on those two topics, to avoid > this problem? I think the configurability of the package makes it hard to say one way is "right" and another is "wrong." It's a safe guess that most people are using group/topic parameters based on the configurations I've been asked to debug. Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-03 21:20 ` Ted Zlatanov 2003-11-03 22:06 ` Kai Grossjohann @ 2003-11-04 21:39 ` Kai Grossjohann 1 sibling, 0 replies; 11+ messages in thread From: Kai Grossjohann @ 2003-11-04 21:39 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > On Mon, 03 Nov 2003, kai@emptydomain.de wrote: >> >> Well, spam is being processed by Bogofilter in my case. Or, put >> another way, the processing I do on spam is to move it to >> INBOX.spam. > > OK, how would you suggest I change the docs and/or implementation? I > understand the problem, I'm just not sure how I can fix it. I think it's better to change the docs. The behavior makes sense: moving spam to a destination group is something that can be done in addition to other processing. (The alternative would be to provide a list of actions, such that moving to another group could be part of it. But that would make the configuration more complex for no apparent gain.) Maybe you could extend the description of M-d. Perhaps like this: Marking a message as spam means that Gnus might do two things with it. First, it can analyze the message (we call it "spam processing"), and secondly it can move the message to another group (which is called the "process destination"). Read on for more on spam processing and process destinations. Further down, it says "you have to collect your spam in one or more spam groups, and set spam-junk-mailgroups appropriately". The following questions come up when you're naive: How to collect the spam in spam groups? Of course, the answer is by hitting M-d and then relying on the process destination to do the collecting. But the docs don't say :-) And secondly, why do I *have* to set spam-junk-mailgroups? Isn't it enough to just process the spam? How does spam-junk-mailgroups come in? Why do I need a group where all new articles get the spam mark automatically? Say I use the black/whitelist thing. Then why is it not sufficient to just blacklist the sender, then delete the spam? I also mentioned a tutorial-type example. It seems that you use spam.el in the "normal" way, in the way that spam.el was intended to be used. So how about you describe your setup, explaining what each configuration item does? Something along these lines: I set nnmail-split-fancy like this: .... This invokes spam-split which puts spam into a specific group. This group is specified by the spam-split-group variable. I have (setq spam-split-group "incoming-spam"), so spam-split will put spam into the nnml:incoming-spam group. From time to time, I enter that group to check whether messages in that group are really spam. If I encounter any ham, I hit M-u on it. When exiting the group, the spam from nnml:incoming-spam is moved to nnml:train-spam and the ham is moved to nnml:train-ham. I do this by setting the group parameter spam-process-destination to nnml:train-spam and ham-process-destination to nnml:train-ham. I then use nnml:train-spam and nnml:train-ham for bogofilter training. I set the spam-processor group parameter for nnml:train-spam to gnus-group-spam-exit-processor-bogofilter, and for the group nnml:train-ham I set the ham-processor group parameter to gnus-group-ham-exit-processor-bogofilter. After being processed by bogofilter, spam from nnml:train-spam will be deleted because of the foo setting. (Ed. note: which setting?) And ham from nnml:train-ham will be moved to nnml:mail.misc because I set the group parameter ham-process-destination on nnml:train-ham accordingly. In the above description, I tried to guess what your, Ted's, setup might be. I'm sure it's wrong. But maybe you get the idea of what I mean by showing the connection. In fact, I think that lengthy paragraph is still too difficult to understand to see the big picture. Hm. We need a summary explaining just what happens. Maybe a drawing would be nice? But I'm really bad at drawing... So, maybe the above should be split into a description what happens and then a description of the settings that are needed to make it happen. WDYT? I could also describe my setup, but I'm afraid that's not really typical. After all, I try to make it server-based, and I guess most users don't have their own server. Kai ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-01 20:17 How to use the spam.el package? Kai Grossjohann 2003-11-03 18:37 ` Ted Zlatanov @ 2003-11-03 20:15 ` Kai Grossjohann 2003-11-03 20:25 ` Ted Zlatanov 1 sibling, 1 reply; 11+ messages in thread From: Kai Grossjohann @ 2003-11-03 20:15 UTC (permalink / raw) Another aside: with the previously described config, marking some messages as spam with M-d, then exiting the group, asks me "Really delete these 42 messages forever?" "Which 42 messages?" I think. "It must be the spam ones. But I didn't tell it to delete the messages, just move them to nnimap:INBOX.spam..." 8-) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-03 20:15 ` Kai Grossjohann @ 2003-11-03 20:25 ` Ted Zlatanov 2003-11-03 21:04 ` Kai Grossjohann 0 siblings, 1 reply; 11+ messages in thread From: Ted Zlatanov @ 2003-11-03 20:25 UTC (permalink / raw) Cc: ding On Mon, 03 Nov 2003, kai@emptydomain.de wrote: > Another aside: with the previously described config, marking some > messages as spam with M-d, then exiting the group, asks me "Really > delete these 42 messages forever?" > > "Which 42 messages?" I think. "It must be the spam ones. But I > didn't tell it to delete the messages, just move them to > nnimap:INBOX.spam..." Are you sure you're using the latest CVS? This was fixed last week, I believe. Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-03 20:25 ` Ted Zlatanov @ 2003-11-03 21:04 ` Kai Grossjohann 2003-11-04 20:57 ` Kai Grossjohann 0 siblings, 1 reply; 11+ messages in thread From: Kai Grossjohann @ 2003-11-03 21:04 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > Are you sure you're using the latest CVS? This was fixed last week, > I believe. Oops. I was too busy to even think of upgrading. Gnah :-/ CVS is now running. Kai ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to use the spam.el package? 2003-11-03 21:04 ` Kai Grossjohann @ 2003-11-04 20:57 ` Kai Grossjohann 0 siblings, 0 replies; 11+ messages in thread From: Kai Grossjohann @ 2003-11-04 20:57 UTC (permalink / raw) Kai Grossjohann <kai@emptydomain.de> writes: > Ted Zlatanov <tzz@lifelogs.com> writes: > >> Are you sure you're using the latest CVS? This was fixed last week, >> I believe. > > Oops. I was too busy to even think of upgrading. Gnah :-/ The new version works fine. Great! Kai ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-11-04 21:39 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-11-01 20:17 How to use the spam.el package? Kai Grossjohann 2003-11-03 18:37 ` Ted Zlatanov 2003-11-03 20:26 ` Kai Grossjohann 2003-11-03 21:20 ` Ted Zlatanov 2003-11-03 22:06 ` Kai Grossjohann 2003-11-04 2:36 ` Ted Zlatanov 2003-11-04 21:39 ` Kai Grossjohann 2003-11-03 20:15 ` Kai Grossjohann 2003-11-03 20:25 ` Ted Zlatanov 2003-11-03 21:04 ` Kai Grossjohann 2003-11-04 20:57 ` Kai Grossjohann
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).