[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nnimap 0.3.11 released
Jake Colman <colman@ppllc.com> writes:
> > I'm beginning to trust the splitting code. A week or two of using it
> > and I'll have my nnmail-split-method eat all mailing list mails, and
> > only read them with nnimap. (Wow, now nnimap is getting somewhere.)
>
> I caught up on the messages posted over the last few days and now I
> am a bit confused. Earlier you stated that nnmail-split-methods
> could not be adapted for nnimap so you would roll your own. This
> message seems to possibly imply that you might be able to use
> nnmail-split-methods for mail read via the nnimap backend. Am I
> misunderstanding something?
Sorry, I'm not making myself clear. To make things clear:
* nnimal-split-method is not easily adaptable to nnimap
* nnimap has it's own splitting mecanism
(What I was trying to say was that since I now read all mailing lists
via nnimap, I have no use for them in my nnfolders so I'll tell
nnmail-split-methods to junk all thoose messages. I still would get
all mail to nnimap since it has nothing to do with
nnmail-split-methods.)
> Ideally, from my perspective, I would want to treat nnimap access to
> my server identically to pop access to my server. Is this too much
> of a utopian request?
No. I only copied my nnmail-split-method and renamed the variable to
nnimap-split-rule and it worked. You would of course have to change
your group names to suit your IMAP server (prepend "INBOX." to all
groups, basicly), and you can't use fancy splitting or functions in
the split rule. Yet.
I'm not sure if nnimap should use nnmail-split-methods, it feels very
wrong.
/S