An idea for an ultra-minimalist mailing list manager. DashL is lightweight in that it uses a single email account, which can be an email account that is in general use by a user, with list mails being routed off to DashL by (eg) procmail. DashL is a script to which mail is delivered; it can be delivered to by setting .forward to pipe to it directly, or by a procmail rule which pipes mail to it. These are pretty normal ways of HandlingMail on unix. How does DashL respond to incoming mail? First, it checks the To header; the address is ignored, but the name is not. The name must end in "-l" (hence the name DashL); if it doesn't, it's ignored. Note that if there are multiple names in the To header, DashL may not work right (although it should do). The part of the name before the -l (and after any preceding whitespace) is taken as the name of a mailing list ("foo-l" -> foo, "The Foo List foo-l" -> foo). The mail is then processed for that list. We might support an alternative delivery mode; on some systems, mail to foo-bar@host is routed to foo@host, with the original address retained in the To header. This is likely to be more robust than relying on names. The supplementary part of the local-part would be taken as a list name, with the requisite -l at the end (eg user-foo-l). Here's how mail is processed: - _If the list exists_ -- _If the sender is subscribed_ --- _If the subject line just says "unsubscribe"_ ---- Unsubscribe the user, and send a confirmation email --- _Else_ ---- Deliver the mail to the list -- _Else_ --- Subscribe the user, and send a confirmation email --- Deliver the mail to the list - _Else_ -- Assert that the subject line doesn't just say "unsubscribe" -- Create a list, and send a confirmation email -- Deliver the mail to the list (pointless, but hey) The behaviour of bounces needs to be worked out; it's vital that a bounced mail doesn't go back to the list. The X-Loop header comes in here. Obviously, DashL keeps a database of mailing lists. This is in plain text, so that the account owner can manage it. The best way to do this would be to have a .dashl folder, with files for each list (named foo.list or something) having one subscriber email per line. There is no automatic method for deleting a list; it's a manual admin task. Note that the account owner can create private lists by manually creating a file which is not writable by the DashL process, and managing its contents by hand. Files are all locked before and during use; in general, DashL can survive the concurrency environment that running from .forward implies. Delivery to a list involves: - Adding a reply-to header - Adding a X-List or whatever header - Prepending [$listname] to the subject line - Sending the message to everyone on the list - Optionally archiving the message (set either globally or on a per-list basis; there could just be a folder called foo.arch in the .dashl folder; note that if this was a symlink, it could be used to automatically webify the list (kinda)) General failure should result in an exit with code 75, which means 'failed; try again" (based on /usr/include/sysexits.h). CategorySoftware