Many U*nix users with advanced email needs, a high load of email, and possibly a lot of addresses to keep separated, invariably come to procmail and to Mutt (but the MCG concept can be easily adapted to other MUAs: read on).

Procmail and Mutt are so flexible and powerful to allow a total customization of email management, whatever your particular needs are, and they automatize many tasks. Furthermore, they are much less resource hungry than many other solution with the same power and flexibility (do they exist?)

In spite of all this, I grew sick of setting options about the same thing, but with two different names in two different files, and in trying to keep those two files in sync. It’s always the same thing, email management, why should I configure things twice?

MCG (Mail Configuration Generator) is meant to solve this problem. I wrote it almost ten years ago, here is a copy of the original MCG announcement. I didn’t even dream to reinvent procmail or mutt. I have written one script which reads one configuration file, and then generates two files that procmail and mutt can include/source every time they start.

Whenever you want to change something, edit that configuration file, re-run mcg, and voila! Of course, all settings not covered by MCG continue to live undisturbed in ~/.muttrc and ~/.procmailrc. I have no intention to completely configure those two tools via MCG, making it as big and difficult to debug as them: just to make (part of) the whole thing a bit faster and easier (Lazyness, Impatience, and Hubris, right?).

The essential thing

MCG is more a state of mind (doing the same thing, in this case email, just once) than the particular script I named in this way. EVERY feedback and bug report is much appreciated (=needed!) but the fundamental thing is to respect the rule (yes, pun intended) above. Practically speaking, patch the script as much as you like, or rewrite an equivalent one for your own MUA/MDA pair, but:

USE THE SAME FORMAT FOR THE CONFIGURATION FILE!!!!!

and help me to make it general. Do the same thing once, remember? Today, it is procmail and mutt. If and when something better comes up, or we just want to experiment for one week with a different MDA or MUA, why in heaven should we redo the mail management thing? Let’s just use a different, properly changed mcg to read the already existing configuration file. It is really time that all Free programs (be they console ones, GNOME, KDE, or the Next Big Thing) doing the same thing share the same configuration format, at least for all those functions/features they do have in common. For that big picture, read about the G3 swamp (update 2011/03/03: that post on Telsa’s website isn’t there anymore, but it was about a GUADEC talk titled Draining the Free Software swamp).

Download and feedback

Thanks for enduring the short lecture above. The script and the configuration file I used to debug this version are zhere.

Unpack, adjust the scripts paths, and see the two files it generates. In some future version the configuration file will become ~/.mcgrc, in the best Unix tradition, but let’s debug it a little first. Feedback should be addressed to mfioretti@nexaima.net

Changelog for version 0.3

  # CHANGELOG:
  #
  # version 0.3
  #
  # 1) to_hdr feature better documented (see below)
  #
  # 2) trailing and leading spaces removed from $MEMBER addresses in __GROUP__
  #    recipes (they would generated errors when sourcing the corresponding
  #    send-hook from .muttrc
  # 3) Line which added default "send-hook ." to .muttrc commented because
  #   send-hook overrides previous folder hooks, i.e. a folder hook loads a
  #   profile, but "send-hook . default seems (at least in my mutt version
  #   (Mutt 1.4i (2002-05-29)) to reload the default profile when replying from
  #   that folder
  #
  # version 0.2
  # (many thanks to Brian Salter-Duke for patches, testing and suggestions on
  #  practically all the improvements listed below)
  #
  #
  # 1) $YEAR substituted by calls to /bin/date (change it if the path to date
  #    is different on your system!! The reason is that mcg generates rules that
  #    mutt and procmail could use even years later so it must leave to them the
  #    calculation of the current year/month. In other words, version 0.1 was not
  #    "Year-2004-compatible" :-)
  #
  # 2) "lists" and "subscribe" are mutually exclusive in mutt
  #    Now there is only one list directive, "lists:" which can be
  #           missing entirely (no list)
  #           'S'           (will add "subscribe" line to $MUTT_RULES
  #           'L'           (will add "lists"     line to $MUTT_RULES
  #
  # 3) "save:" directive added, to customize save-hook. Currently, it behaves as
  #    follows:
  #          missing entirely: default save (to ARCHIVE/YEAR.FOLDERNAME)
  #          '-'             : do not generate save-hook
  #          'ym'            : save to  ARCHIVE/YEAR.MONTH.FOLDERNAME
  #          (other values to be added here in the future?)
  #     IMPORTANT: to change the default save-hook, just edit accordingly
  #     $SAVE_HOOK
  #
  # 4) Added support for groups of random addresses (ex students in one class)
  #    Now, one entry like:
  #
  #     name:           myfamily
  #     address:        me@here.com, wife@there.com, son@college.com
  #     profile:        profile.family
  #     recipe:
  #        __GROUP__
  #        __DESTINATION__
  #     end:
  #    should create a folder myfamily in which procmail will put all the messages
  #    From: any of the listed addresses. CAUTION! Procmail recipe generation is
  #    *not* one of my strongest skills, please triple-check that part (i.e. where
  #    the __GROUP__ marker is used. Furthermore, send-hook directives binding
  #    those addresses to the profile specified will be created
  #
  #  5) Added a "tohdr:" directive which adds a "my_hdr To:" to muttrc
  #
  #  6) Added creation of folders if not existing. This is mbox format only, and
  #     must be enabled by setting $CREATE_FOLDERS to any numeric value > 0
  #  7) Added loading of default profile (profile.default)