Re: nnimap and crossposting (Re: Moving from nnml to nnimap...)

[Ken Raeburn <raeburn@raeburn.org>]

Simon Josefsson <jas@extundo.com> writes:
> Hm.  What about: when marking an article, use the current
> nnimap-split-rule to determine which groups would receive the current
> message, and then use the imap-search logic above on only those
> groups, to find any crossposted copies?  Will probably be rather slow
> anyway, and assumes nnimap-split-rule knows about all split rules, but
> it is an improvement.

Good idea ... except that one of my group names is constructed when
the init file is loaded, using (format-time-string "all.%Y-%m").  And
if I get to use Sieve eventually, the spam rating calculation, at
least, would be likely to differ between Gnus and Sieve.

I want those format-time-string groups to be "all mail I got during
month X and haven't deleted", so I can search for messages I got, but
am not sure from what list, as long as I know approximately when,
without having to pull down a summary of *all* my mail.  If I had a
way to do that with Gnus, I could probably make do with it being one
group instead of one per month.

If I could specify a date range with an nnvirtual group, and have that
range propagated into a search on any component nnimap groups, I could
probably even make do with a huge nnvirtual group to gather together
all the list-oriented and other groups.  That wouldn't eliminate
cross-posting, but it would cut out a lot of it.

> I think the nnmail split-log already is permanent, it is used for,
> e.g., `nnmail-split-fancy-with-parent' which have similar needs (e.g.,
> find destination groups for earlier messages based on message-id).

Ah, you mean the nnmail message-id cache file?  Good point.  But I'd
have to set nnmail-message-id-cache-length to something absurdly
large, or the data will get thrown away.  It defaults to 1000, which
won't have nearly the same performance problems as a complete list.
(And see the aforementioned problems with Sieve.)

> When nnimap crosspost split an article into several groups, it add
> client-specific message flags on each message, indicating the mailbox
> and article number of the other crossposted copies.  For example, if
> article 4711 in mailbox INBOX.foo have a mark
> gnus-crosspost-INBOX.bar-42, then when marking INBOX.foo:4711 the same
> mark be applied to INBOX.bar:42 as well.  There is one immediate

I'm told some IMAP servers like Cyrus will limit the number of flags
to something like 32 per mailbox.  Even listing the group names and
not the message numbers would quickly exceed that limit.  A single
flag, gnus-(not-)crossposted, might be enough to tell Gnus whether or
not the other groups need to be scanned, but it would still suck to
have to rescan all of them.

Too bad IMAP doesn't allow arbitrary client-defined string attributes
for messages...

Ken