Re: mailing list vs "the futur"
On Fri, Aug 10, 2018 at 11:46:12AM -0000, Dan Purgert wrote:
> Not familiar with procmail. A quick perusal of the manpage seems to
> indicate this is a local mail "processor" for sorting things, as opposed
> to say something on the mailserver itself?
Correct. Procmail uses a set of rules to decide what to go with messages
presented to it; those rules are usually based on the contents of message
headers, but don't have to be. For example, for this mailing list:
:0:
* ^X-Mailing-List:.*<debian-user@lists.debian.org>
/home/rsk/linux/debian-user
Translating, this means that any message which has the specified header
will be appended to the file named in the last line. (It would be nice
if the debian lists complied with RFC 2919 by using List-Id, but at least
this header works and is consistent throughout.) The small regexp in
there is present because the functional part of the header is the text
in angle brackets; any text preceding it is for human consumption,
and may change (or not be present at all).
A typical usage pattern for procmail might be something like this:
mail server -> fetchmail -> procmail -> mail client
In other words, a program like fetchmail is used to retrieve mail
(via POP or IMAP) from a mail server. Fetchmail hands off each message
to procmail. Procmail decides what to do with each message, which usually
means filing it. [1] The user can then read each mailing list by pointing
their mail client at it. This also accumulates a per-mailing list
archive (in mbox format), which is useful.
This is a highly scalable, very robust setup for anyone who has to
deal with lots of mailing lists or with correspondence involving diverse
groups of people. It scales to thousands of rules (I have 3000+ as
of this morning), it executes quickly, and because procmail is careful
to Do The Right Thing even under adverse circumstances, it's rather
tolerant of configuration errors. Happily, most mailing lists now
support RFC 2919 (or at least something functionally equivalent,
as we see here) so it's not often necessary to craft procmail rules
based on other headers.
---rsk
[1] Although it could also mean forwarding it, duplicating it, discarding
it, etc. For example, there exists a mailing list called "outages", which
is used to announce and track outages of networks and other operations
of interest. If you're subscribed to outages and have a particular
interest in certain ASNs or operations, you can easily craft a procmail
ruleset specific to those that (a) files a copy of the message as above
and (b) upon a relevant Subject-line match, submits a duplicate copy of
the message to an internal ticketing system so that it becomes visible
to operations staff, and so that it can be tracked in the same way as
other trouble reports.
Reply to: