1

as the linux kernel mailing list is really noisy, I want to discard all mails which are send to my mailbox from the LKML, but which are not from me, to me or as answer to one of my mails. I do already do some filtering and redirect all patch-mails (including [PATCH at the beginning of the subject) to another inbox as the "normal" LKML mails. But it is still much too much.

How to do this with procmail?

What I have atm:

:0
* ^Sender:\ linux-kernel-owner@vger\.kernel\.org
* (PATCH|patch)
$MAILDIR/ml.kernel_org.linux-kernel.patches/
musicmatze
  • 4,124
  • 7
  • 33
  • 48

1 Answers1

1

The real challenge here is to articulate how to reliably identify messages which are replies to something you wrote. Are you satisfied with excluding messages which are To: or Cc: yourself?

:0
* ^Sender: linux-kernel-owner@vger\.kernel\.org\>
* ! ^From: Your Self <you@example\.net>
* ! ^TO_you@example\.net\>
/dev/null

(obviously, edit the addresses to match what your mail client really puts there).

Or perhaps you have a vanity domain, in which case (properly constructed) replies will have an easily identifiable Message-Id of yours at the start of References:?

:0
* ^Sender: linux-kernel-owner@vger\.kernel\.org\>
* ! ^From: Your Self <you@example\.net>
* ! ^TO_you@example\.net\>
* ! ^References:[  ]*<[^<>@]*@yourdomain\.example\.net>
/dev/null

(the whitespace inside the square brackets should be a tab and a space).

Or you could expand that a bit to look for your domain anywhere in References:, to also include replies to replies to yourself, if you want that.

Or you could keep a local copy of all your outgoing message-id:s and look for them in References:, but that is already a significant endeavor which I will only point out as a possibility if you cannot use any of the above. (I do believe it has been hashed out in more detail before, perhaps on the Procmail mailing list.)

As an aside, I would change the "patch" rule to only examine the Subject: line. A match on "patch" in any other header is extremely likely to be a false positive. If you want to examine the body, you need extra flags, perhaps like this:

:0
* ^Sender: linux-kernel-owner@vger\.kernel\.org\>
{
  :0
  * ! B ?? \<patch\>
  * ! ^Subject:(.*\<)?patch\>
  { }  # empty "then", just so we can continue to "else"
  :0E
  $MAILDIR/ml.kernel_org.linux-kernel.patches/

  # While we are inside these braces, let's continue with other LKML stuff
  :0
  * ! ^From: Your Self <you@example\.net>
  * ! ^TO_you@example\.net
  /dev/null

  # Any additional LKML recipes? Add them here

  # Anything which falls through here is regular LKML
  :0
  $MAILDIR/ml.kernel_org.linux-kernel/
}

(This can obviously be refactored in a number of different ways. Remember De Morgan's laws: NOT (A OR B)<=> NOT A AND NOT B.)

As a safety measure, you might want to look for messages which actually carry a patch as an attachment, rather than filter the discussion about such messages? That can also become quite complex, because there is a number of different ways to represent a patch as a MIME attachment (and some are also sent completely in-line, in a regular text/plain part amongst other text) but that isn't insurmountable, either, just significant drudgery.

tripleee
  • 175,061
  • 34
  • 275
  • 318
  • For the second example: I think I could escape the whitespace like so: `[\ \t]`, couldn't I? For the last example: The last `# While we are ...` filters _all_ LKML mails, doesn't it? "Normal" LKML mails go to another mailbox in my setup,... I could include this rule inside the braces, right? – musicmatze Jun 03 '14 at 06:32
  • Procmail doesn't support `\t` for tab. Yes, the intent is that you would do your other LKML processing inside the braces so you don't have to repeat the first condition, and to keep everything nicely grouped. I'll add a final action inside the braces to make this clearer. – tripleee Jun 04 '14 at 03:48