Just an aside... On 05Jun2020 16:15, mutt...@mail.com <mutt...@mail.com> wrote:
To explain: I have a number of different email accounts on a number of different servers, and I do that for a number of reasons, one being that my email is then effectively pre-filtered.
Separating work and personal email is well worth doning anyway, not just for the filtering.
I've a remark about your procmail...
Work email goes to, say, some...@example.com, non-work email to someb...@example.org, and so on. I want that to be the case with my local email experience as well, so I've set up procmail to deliver into different directories depending on where the email comes from/to: # work :0: * ^(From|Cc|To).*some...@example.com Work/ # play :0: * ^(From|Cc|To).*someb...@example.org Play/
Maybe I'm misreading your setup, but I presume you're fetching from different mailboxes here? Fetch from work, fetch from personal, etc? If so, I'd use distinct procmailrcs altogether - no reliance on the addresses in the headers (which are unreliable); instead process the work messages with one set of rules and personal by another, done by supplying a "work procmail" when fetching from work etc.
OTOH, if work and personal just forward to some common mail address then you're in split up the premixed stream, and back into rules of the form you're already using.
In my case, I pull from a work mailbox into a distinct spool, and process that spool as "from work" using the "work rules". Entirely distinct from the personal rules.
Now, as it happens, the work rules in my case go "take a copy to the work folder for cross referencing, then file the message in the common spool". Which then runs my common rules for a mixed stream just like yours.
But the initial file deduces work vs personal from the fetch source, not the header contents.
Cheers, Cameron Simpson <c...@cskk.id.au>
