Gnus development mailing list
 help / color / mirror / Atom feed
From: "Ted Zlatanov" <tzz@lifelogs.com>
Cc: ding@gnus.org
Subject: Re: Spam splitting and multiple nnimap methods
Date: 19 May 2004 10:48:44 -0400	[thread overview]
Message-ID: <4nhduch3qr.fsf@lifelogs.com> (raw)
In-Reply-To: <20040518181911.A3167@gwyn.tux.org> (Timothy Brown's message of "Tue, 18 May 2004 18:19:11 -0400")

On Tue, 18 May 2004, tim@tux.org wrote:

On Tue, May 18, 2004 at 03:11:49PM -0400, Ted Zlatanov wrote:

>> I actually meant to write cross-server splitting, which would allow
>> "nnimap+server.com:externalgroup" but I keep forgetting about it.
>> No one seems to be clamoring for it, so I guess it's not that
>> important.
> 
> Clamor! Clamor! That would be good stuff.  You know, the reason I moved
> to Gnus is it really handled multiple mailboxes and IMAP servers "well",
> and it was the only client to do so and have everything displayed in a
> way that made sense, other than Thunderbird which doesn't work for me
> due to my reliance on text-based terminals, etc.  Cross-server splitting
> would, for instance, allow me to treat all messages universally as part
> of a single server, thus creating a kind of "IMAP proxy" setup.  But perhaps
> kibozed groups offer me the same functionality(?) - haven't looked into
> this.

They don't.  If anyone else would like cross-server splitting, speak
up.

>> > This is one area where Gnus' flexibility is giving me a huge
>> > headache - the manual just isn't clear enough.
>> 
>> This is my fault, since I wrote most of the spam support
>> documentation.  I've had help from several volunteers with the
>> manual; if you would like to help as well that would be great.
> 
> I didn't mean to point fingers, but the information you've provided here
> has really helped to clarify the process.  (But see below...)

I'm saying that I would appreciate any volunteer help with the
manuals, not that you are being too critical.  I often feel like I'm
too close to spam.el, so I don't realize how strange and complex its
features are to most people.

>> You should not split back into INBOX.  It's been done, but it's
>> unnecessary.  Make your last split group "mail" for example and
>> you'll be happier.
> 
> The behavior I really want is:
> 
>   1) Go through INBOX, detect whether mail is bogo-spammed or in a blacklist.
>   	a) Move this mail to the spam folder.
> 
>   2) Read the INBOX, and manually mark what bogofilter didn't clue in on as
>   	spam.
> 
>   3) Leave INBOX, and have the remaining mail that's there trained
>   as ham.

I do this, but instead of INBOX I use "mail," and I only train on ham
that's misidentified as spam.  Your approach to training and spam
detection is just as valid.

> You mention that I shouldn't split back into INBOX; can you explain why this
> is unnecessary and/or bad?  I'm trying to figure out why it makes sense
> to have to have a different folder as my INBOX (although i'm not against
> the idea, i'd like to leave INBOX to its intended purpose and expire mail
> into INBOX.mail later)

Splitting back into INBOX is, in fact, possible - Uwe Brauer reported
back in October 2003 that it works:

http://groups.google.com/groups?selm=m3ekxv2ufx.fsf%40maport01.mat.ucm.es&output=gplain

but I think you'll do yourself a disservice if you respool back into
INBOX.  At the very least, you will be respooling the same messages
again and again if you don't clear them out of INBOX.  Also, all Gnus
splitting is oriented towards splitting things out of the INBOX, not
filtering in place.

But if you want to use INBOX, you can.  Just make sure to report any
bugs that you observe in the process.

>> Each IMAP server with a nnimap server entry in your Gnus setup can
>> have its own split rules.  This is my setup, for instance:
>> 
>> (setq nnimap-split-rule '(
>> 		     ("lifelogs" ("INBOX" nnimap-split-fancy))
>> 		     ("imap" ("INBOX" nnimap-courier-split-fancy))))
>> 
>> as opposed to the simpler but less useful:
>> 
>> (setq nnimap-split-rule 'nnimap-split-fancy)
> 
> This sheds a ton of light on how nnimap can fancy split using individual
> servers, thanks.  In these rulesets, you're only specifying folder names
> and not fully qualified nn<backend>+etc. stuff, right?  This really needs
> to go into the fancy splitting section or the IMAP section of the
> manual.

I got the information from C-h v nnimap-split-rule, but it's also in
the manual.  Maybe it should be more prominent, but I don't know that
multiple IMAP servers are a very common configuration.

> I follow all this.  What isn't clear is what the 'Spam Autodetection'
> feature is used for, and/or if it needs to be enabled (in G c), etc.

This was answered by Jonas Steverud.  It's also in the manual.

> This has all been really helpful.  To summarize and make this as clear
> as possible:
> 
>   - I want to scan for spam in every IMAP mailbox I have.
> 
>   - If mail appears as spam based on what bogofilter and/or the blackholes rule
>   	knows, then dump it in a spam folder that is individual to that IMAP
>   	server.  Later SpamAssassin (via spamc) will be added to the mix.
> 
>   - I'll also scan through this folder after it's done, read the mail I want to
>   	read, mark certain things as spam, and treat everything else as ham.
> 
>   - Spam and ham will be processed on group exit.
> 
>   - It would be great if that folder was 'INBOX', but I understand if it has to
>   	be 'mail'.
> 
>   - I don't care about other folders at the moment.
> 
> My only real concerns at this point about the above are the
> weirdness i've seen with splitting back to INBOX and never seeing
> the messages in Gnus, but I'll bet that is a small problem.

OK, I hope you'll come through unscathed :)

Remember you can set topic parameters that work just like group
parameters.  So you can say, for a whole topic, "the spam and ham
exit processor is bogofilter" instead of specifying it for each
group.  That simplifies things.

Make sure to keep backups of your INBOX!  You can use something like
my ifrom tool at http://lifelogs.com/source/ifrom.txt or whatever is
appropriate on the server side.  In theory no mail should be lost but
there's only you and Uwe splitting back into INBOX that I know of.

Ted



  parent reply	other threads:[~2004-05-19 14:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-17 21:50 Timothy Brown
2004-05-18  9:53 ` Jonas Steverud
2004-05-18 12:53   ` Timothy Brown
2004-05-18 13:50     ` Jonas Steverud
2004-05-18 14:02     ` IMAP Splitting with multiple mailboxes (was Re: Spam splitting and multiple nnimap methods) Timothy Brown
2004-05-18 14:13       ` IMAP Splitting with multiple mailboxes Kai Grossjohann
2004-05-18 14:15         ` Timothy Brown
2004-05-18 15:53           ` Kai Grossjohann
2004-05-18 15:58             ` Timothy Brown
2004-05-18 16:14               ` Kai Grossjohann
2004-05-18 14:13     ` Spam splitting and multiple nnimap methods Jonas Steverud
2004-05-18 19:11     ` Ted Zlatanov
2004-05-18 22:19       ` Timothy Brown
2004-05-19 11:36         ` Jonas Steverud
2004-05-19 14:50           ` Ted Zlatanov
2004-05-19 14:48         ` Ted Zlatanov [this message]
2004-05-20 10:27       ` Yair Friedman
2004-05-20 18:49         ` Ted Zlatanov
2004-05-22 23:45           ` Lars Magne Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4nhduch3qr.fsf@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).