How I'm currently handling the mailing lists I read

June 19, 2017

I recently mentioned that I was going to keep filtering aside email from the few mailing lists that I'm subscribed to, instead of returning it to being routed straight into my inbox. While I've kept to my decision, I've had to spend some time fiddling around with just how I was implementing it in order to get a system that works for me in practice.

What I did during my vacation (call it the vacation approach) was to use procmail recipes to put each mailing list into a file. I'm already using procmail, and in fact I was already recognizing mailing lists (to insure they didn't get trapped by anti-spam stuff), so this was a simple change:

:0:
* ^From somelist-owner@...
lists/somelist
#V#$DEFAULT

This worked great during my vacation, when I basically didn't want to pay attention to mailing lists at all, but once I came back to work I found that filing things away this way made them too annoying to deal with in my mail environment. Because MH doesn't deal directly with mbox format files, I needed to go through a whole dance with inc and then rescanning my inbox and various other things. It was clear that this wasn't the right way to go. If I wanted it to be convenient to read this email (and I did), incoming mailing list messages had to wind up in MH folders. Fortunately, procmail can do this if you specify '/some/directory/.' as the destination (the '/.' is the magic). So:

:0:
* ^From somelist-owner@...
/u/cks/Mail/inbox/somelist/.

(This is not quite a complete implementation, because it doesn't do things like update MH's unseen sequence for the folder. If you want these things, you need to pipe messages to rcvstore instead. In my case, I actually prefer not having an unseen sequence be maintained for these folders for various reasons.)

The procmail stuff worked, but I rapidly found that I wanted some way to know which of these mailing list folders actually had pending messages in them. So I wrote a little command which I'm calling 'mlists'. It goes through my .procmailrc to find all of the MH destinations, then uses ls to count how many message files there are and reports the whole thing as:

:; mlists
+inbox/somelist: 3
:;

If there's enough accumulated messages to make looking at the folder worthwhile, I can then apply standard MH tools to do so (either from home with standard command line MH commands, or with exmh at work).

It's early days with this setup, but so far I feel satisfied. The filtering and filing stuff works and the information mlists provides is enough to be useful but sufficiently minimal to push me away from actually looking at the mailing lists for much of the time, which is basically the result that I want.

PS: there's probably a way to assemble standard MH commands to give you a count of how many messages are in a folder. I used ls because I couldn't be bothered to read through MH manpages to work out the MH way of doing it, and MH's simple storage format makes this kind of thing easy.


Comments on this page:

The command you are looking for is folder(1) I think.

That said, I use one folder per mailing list that has more than 3 messages a day anyway, and couldn't imagine otherwise. :) (Or I use gmane.)

By cks at 2017-06-19 14:29:12:

The downside of folder is that it doesn't just report a count, it also has the side effect of changing your current folder. It's possible to get around this by setting $MHCONTEXT to /dev/null before running folder, but if I just want a minimal count I also need to do something to change folder's output.

(Changing folder's output somehow is important because I want to suppress all output for empty folders. In the case where no mailing list has pending email, mlists is intended to be completely silent.)

By opk at 2017-06-19 19:11:23:

For what it's worth, there's also flist which, unlike folder, can list multiple folders. My alias for it includes the MHCONTEXT=/dev/null trick to avoid changing folder.

Written on 19 June 2017.
« One reason you have a mysterious Unix file called 2 (or 1)
Plan for manual emergency blocks for your overall mail system »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jun 19 00:17:57 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.