[ Hans-Albert's homepage (in German) ]

SmartList Recipes

These are some rc.local files for use with SmartList, a procmail based mailing-list software.

rc.local.s00.approve-foreign
Goal: Allow the maintainer of a "closed list" to approve mails from non-subscribers. A "closed" list normally only allows submission from subscribers. To achieve this with SmartList, you unset foreign_submit, have accept linked to dist (the default), and place some alternate addresses of your subscribers into accept2.

How to configure the list: Use these recipies in rc.local.s00.

The variable $moderator_PASSWORD (set in rc.custom) needs to be set to a regular expression that matches the password(s). In the most simple case, this is just the password itself, but $moderator_PASSWORD may also match a whole set of passwords. (See the recipe file for an example.)

How to use it: As the maintainer, you add an Approved: header line with a valid password to the message, then resend ("redirect", "bounce", or whatever your mail program calls it) it back to the list. The list will remove that header line, so the password is not revealed to the list members.

Behind the scenes: It checks approval the same way a moderated lists checks it: If the body starts with the word "Approved:", it is pulled into the header (by concatenating header and body (1) (2)). Then, the new header is checked for a valid Approved: header line. If it is found, moderated_flag and foreign_submit are both set to yes. The former causes the removal of the Approved: header, the latter causes the mail to be forwarded through the list, despite the fact that the original sender is not subscribed.

(1) This is intended to allow moderators to also use mail programs that do not allow their users to add arbitrary header lines to messages.
(2) Make sure there is an empty line before the forwarded message starts (a really empty line, not even a space may be on that line). Else, everything (or at least the beginning of the message) will become part of the header. At best, this would confuse your list members, because they will only see part of the message. At worst, it would confuse some mailing software on the way, causing it to throw the message away.

Alternative Solution: In a mail to the SmartList discussion list, Tim Pierce pointed out that there is an even simpler solution: Just add the maintainer to the accept2 file.

rc.local.s00.toolarge
Messages that exceed a certain size (defined as $size_limit in rc.init and rc.custom) are normally not resent to the list, but get a special header line and are forwarded to the maintainer only.

Goal: If this happens, tell the sender about it. A copy of this mail draws the maintainer's attention to the problem mail. Allow the maintainer to resend this message despite its size.

The story behind: Being subscribed to several of the lists I maintain (though not all of them), I sometimes do not notice that the message I am just reading did not reach the other members of the list, but has been forwarded to the maintainer (me).

In late May 2001, that even happened with a list to which I am not subscribed. (And that was a support list; thank Jove the customer's reaction was not to unfriendly.) A colleague suggested that in such cases a notification message should be sent to the originator of the mail, so s/he knows that the message was not lost.

I accepted his idea, and decided that this notification should also go to the maintainer, so I (or whoever is the maintainer) get aware of that problem.

How to configure the list: Use rc.local.s00.toolarge as rc.local.s00 (or pull it in via INCLUDERC=...).

Behind the scenes: If a mail comes in to the list that exceeds $size_limit, the script toolarge gets invoked to inform the sender of this fact, with a copy of the notification being sent to $maintainer to attract her/his attention.
The submission itself is further handled by rc.submit, which passes it to the maintainer for being too large.

If, however, the mail comes from the list maintainer, or carries a correct Approved: header (like for a moderated list), the mail passes through. To avoid that rc.submit suppresses the mail again, $size_limit is increased. (Note: As none of my lists is moderated, I am not sure whether the "Approved:" part works. The relevant parts are copied from rc.submit, so I expect it to work the same way.)

rc.local.s10.mhonarc
Store submissions to an HTML archive. This uses MHonArc to maintain the archive. The archive is per year, but that can easily be changed to per-month or per-week (or even per-second smiley)
For more ideas about HTML archives with MHonArc, see my MHonarc section.
rc.local.s20.mmmyy
Archive the message to directory archive/Jul94 etc. and preserve the number it got.
subscribe.files
A mail giving a few explanations concerning this file. It contains commands for the archive server that are executed on behalf of new subscribers. This allows list maintainers to automatically send some information to the newcomers. On some of my lists, I use this to send the help file (how to (un)subscribe etc.) and an informational file saying something like "This is the XY list. Its purpose is ... A web archive is at ...".

UNIX date command

Some of the rc files use the UNIX command date to get the current month, year, or whatever. It takes the form

date "+format"
(You may use single or double quotes). In format, %Y is replaced by the 4-digit year, %y by the 2-digit year, %h by the abbreviated month name (Jan, Feb, ...), %m by the month number (01..12), %d by the day number (01..31). For example, to get something like 2000-11-20 (for Nov 20, 2000), use %Y-%m-%d in the format string. For more possibilities, consult the manual page (type "man date" on the command line)--they seem to vary with the different UNIX flavors and versions.


Disclaimer: The opinions expressed here are mine, except those expressed in quoted material (including, e.g., mail messages). The fact that I am quoting them in no way implies that I share their opinions. Nor does the fact that my web-pages link to other web-sites imply that I share any opinion expressed there.

(Sorry if this disclaimer confuses you; German jurisdiction has made some decisions in the past that make such a disclaimer necessary.)

Hans-Albert Schneider
Last modified: Thu Oct 25 22:08:21 CEST 2001