Re: Gnus5, procmail, and reading mail lists.

[steve@miranova.com (Steven L. Baur)]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

>>>>> "SLB" == Steven L Baur <steve@miranova.com> writes:

    Per> If you use procmail, I suggest using the following code to
    Per> sort out duplicates (stolen from someone on the procmail
    Per> list):
...

You might want to adjust the 8192 upwards if processing a lot of mail ...

That's cleverer than the brute force method in the procmail docs.  There
are two problems with that approach that bother me.  And they're both
related.

If I ran that recipe before splitting mail for this list into its
place, I would definitely have all replies to message I write archived
ahead of the actual message.  This may not really be a problem, but it
is a nit.

Secondly, I am a bit of a neat freak with respect to saving mail.  I
want all the original (incoming) headers saved, and for mailing list
mail, I want only messages with headers coming from the list owner.

(I feel strongly about this now, because I allowed some non-Gnus
mailing list stuff to get mixed in with the ``real'' stuff, and spent
a lot of time, correcting it.  Never again.)

This recipe is first come first served, and the e-mail courtesy copy
(with the wrong, for me, headers) will get placed in my general
mailing list folder if it arrives first.

I see two other possible (stronger) solutions.
One can get more creative with the procmail recipe.  First separate
out all mailing list mail with proper mailing list headers.  Second,
take all the mail that matches a TO: <all-mailing-lists> and separate
*that* out into a duplicates folder.  I can see how to do that with
some ugly duplicated procmail recipes.

The second possibility, is to put Gnus to work with secondary
splitting.  Sort out all mailing list stuff by official headers (as
above), and let the rest go into a general folder.  Allow Gnus to do
splitting on the general folder only, and have it catch the duplicate
CC: to a mailing list stuff.

I don't know which of these two methods would be the easiest to
maintain.

-- 
steve@miranova.com baur