There will be one mail server (or a group of servers coordinated such that they act like a single server) somewhere to which all messages addressed to <name>@nesfa.org, <name>@boskone.org, or any other NESFA email address is delivered.
We must be able to set up more than one person as able to perform each manual function, to minimize single points of failure.
We must be able to administer and process email independently in each of our domains (NESFA.ORG, NESFA.COM, BOSKONE.ORG, NESFAPRESS.ORG, NESFAPRESS.COM) except that we should choose to combine nesfa.org with nesfa.com and nesfapress.org with nesfapress.com such that messages sent to either member of a pair are handled in exactly the same way. We must be able to handle limited mail for other systems within our domains (e.g., webmaster<at>www.nesfa.org as required by RFC 2142).
All administration of mailing lists (except possibly for creation and deletion) can be done via an email and/or secure web (HTTPS) interface. Creation and deletion of mailing lists, all administration of aliases, and all other maintenance may require logging in to the server (possibly via SSH for security). We must be able to create and control any number of mailing lists, aliases, and forwarding lists, independently in each of our domains, with full control over all of their characteristics.
There should normally be no noticable delays in processing messages or administrative requests; these actions can be triggered immediately by the arrival of an email message, an action taken on a web site, or however else the action is requested. Any setup which does include planned delays (e.g., polling for messages) must limit the total delay for any request to at most 5-10 minutes. We must recognize that there will sometimes be unplanned delays (e.g., when some part of a system or network is down or overloaded) and consider the appropriate balance between the cost of the overall system and the possible delays or disruptions.
The mail server must have a reasonable anti-spam setup, either one provided by the ISP if its behavior is acceptable to us or one provided and maintained by us with any processing done by the ISP completely bypassed. (While this is generally not important for closed mailing lists, it does matter for open mailing lists and aliases.) The definition of reasonable includes that it generate few, if any, false positives and that (unless we can guarantee that there are never any false positives) no messages are ever dropped without reporting a permanent error to the sender. (This implies that spam-checking must be completed before a message is accepted by the server, since after that time only the unreliable 'from' header value is available for error reporting; using only the SMTP status code to reject messages prevents 'real' messages from disappearing 'without a trace' while avoiding mail-bombing the victim of a forged 'From' header with error messages regarding something he never sent.) What else should it include?
All messages which pass the anti-spam tests must be checked for viruses (except that this is not needed when attachments are prohibited or stripped). The mail server must have a reasonable anti-virus setup, either one provided by the ISP if its behavior is acceptable to us or one provided and maintained by us with any processing done by the ISP completely bypassed.Regardless of the above, all messages to 'postmaster' (in any case, e.g. 'Postmaster', 'POSTMASTER', 'pOsTmAsTeR') at any of our domains should be delivered without any modification (see section 4.5.1 of RFC 2821).
We need the ability for messages for some addresses to be picked up at the clubhouse (probably via POP). For example, eventually we'll have to process emailed reports from Publishers' Storage there.
Many of the aliases and mailing lists should archive messages. What capabilities should an archive have to meet our needs? View messages selected by date, thread, sender, receiver, etc? Web or email interface (or both, or something else)? How to handle access control? What is the plan to backup the archives?
How hard do we need to make it for someone to circumvent our access controls? (This will vary among different functions, depending on the cost to us of a breach.) How do we identify people for determining access? (Remember that it is trivial to, e.g., forge the 'from' header of an email message.)
The ability to send messages as from <name>@nesfa.org,
<name>@boskone.org, or any other NESFA email address with all
headers consistent with that origin. See also Another Email Issue.
RFC 2142 requires that specific email addresses be set up on systems which provide certain services, and for the top-level domain containing any such systems. All of these names must be accepted regardless of case (even very mixed case). An immediate automated response (with suitable protection against mail loops) is recommended.
These names should exist in all our top-level domains (NESFA.ORG, NESFA.COM, BOSKONE.ORG, NESFAPRESS.ORG, NESFAPRESS.COM):
|abuse||abuse of the network|
|?||noc||network infrastructure problems|
|www||[alias for webmaster]|
In addition, all of our systems which host websites (currently www.nesfa.org, www.nesfa.com, store.nesfa.org, www.boskone.org, www.nesfapress.com) need MX records pointing to a system which will handle email for 'webmaster' and 'www' in those domains. [We should also set up www.nesfapress.org to redirect to our website, and set up email for it too.]
For each mailing list <list>@<domain> there should be an administrative mailbox named <list>-request@<domain>.
The DNS SOA record for <domain> should always specify HOSTMASTER@<domain> as the zone's administrator.
We have several different things which people tend to lump under the general label of 'mailing lists', but they have different requirements.
aliases -- these forward messages sent to a NESFA email address (typically from outsiders) to one or more people without the complexity of using a mailing-list manager. They are set up and modified by an administrator. For some of these addresses, we want to archive all messages sent to the alias and all replies to those messages. Such archives should be accessible only to people explicitly granted access by an administrator. For some aliases we may want to insert an identifying token at the start of the 'Subject' header and/or insert a custom identifying header (to make it easier for the recipient(s) to separate these messages from their other email traffic). Aliases should not strip or reject attachments. Messages should appear to be from the original sender.
Some aliases will forward to a [list of] triage person[s] (e.g., Sharon for info<at>nesfa.org) who will examine each message and forward it to an appropriate person for action; these need to be further tweaked so that by default replies to the forwarded message go to the original sender (and also to the triage person[s], so that they can be aware of the status of each message).
redirectors -- forward to the one person who handles that function. Examples would be sales<at>nesfa.org (which IIRC redirects to Mark Olson's home and work addresses) and info<at>nesfa.org (which IIRC redirects to Sharon's home address). By default, replies to any messages sent to a redirector should go to the original sender.
exploders -- forward to a small list of people any of whom can handle that function. Examples would be the Boskone 40 versions of artshow<at>boskone.org (forwards to Ted Atwood and Gay Ellen Dennett) and program<at>boskone.org (forwards to Jim Mann and Priscilla Olson). By default, replies to any messages sent to an exploder should go to the original sender and also to the exploder -- so that all of the handlers for that function remain aware of what actions other handlers have taken.
true mailing lists -- created or deleted by an administrator, but maintained by a list owner and by the list members. For most lists, we want to archive all messages sent to the list. Such archives should be accessible only to list members and to other people explicitly granted access by an administrator. All mailing lists should insert an identifying token at the start of the 'Subject' header and/or insert a custom identifying header (to make it easier for the recipient(s) to separate these messages from their other email traffic). Some lists will strip attachments or reject messages containing them, and all lists should reject 'HTML' messages and may reject 'multipart/alternative' messages; when any message is modified or rejected the sender must be notified. Messages should appear to be from the original sender. The mailing-list manager should provide the 'list-*' headers defined in RFCs 2369 and 2919.
While it would certainly be nice to have only one copy of any message sent to multiple mailing lists delivered to each person who is a member of more than one of those lists, it's not clear that any extant mailing-list managers can do this. Unless I'm missing something, mailing-list managers have separate addresses to receive mail for each list that they manage, a separate copy of a message sent to multiple lists is delivered to each relevant address, and it's difficult at best to rejoin those message copies once they've been separated. The only obvious (to me) ways to make this work would be to integrate the mailing list manager with the mail transfer agent (so separate copies are never made) or to configure the mail transfer agent to deliver all messages for all lists managed by a single list manager to a single address after putting all of the original list-address information into some special header -- but I'm not aware of any mailing-list managers which work this way.
There must be a web and/or email interface which allows anyone to query which, if any, lists they are on and to unsubscribe from any list they are on, which allows anyone to query which lists exist on this server, and which may (configurable per-list) allow other actions. All requests to be added to a list (except those by an administrator) must be confirmed (by sending a message containing an unpredictable token to the address being subscribed and requiring a reply which includes that token) before the address is actually added to the list (to prevent malicious subscriptions by third parties). Any list which accepts subscription requests should have an optional blacklist, to prevent spammers or other known troublemakers from joining. Any 'open' list (one where there is any way to join the list which does not require the explicit approval of a list owner) must either strip all attachments from incoming messages or reject such messages and must not have any automated way for a non-owner to obtain a list of the addresses of its members.
Features wanted (via a web and/or email interface): get and set current list options for a member(*), show all lists with a specified member(*), show all members of a list, show all lists on this server(+), subscribe(*) (perhaps referred to a list owner for approval), unsubscribe, periodic posting of list members to each list (optional), set 'reply-to' to list or original sender, add sender's 'full name' to message (optional), log actions by list owners (including which owner performed them). (*) Anyone may perform these functions for his own address. (+) Anyone may perform these functions.
Options for each member address: receive status (none, plain-text digest, MIME-compliant digest, individual), posting status (none, with approval, OK, whitelist -- bypass spam and other checks), acknowlege receipt of posted messages, don't send messages back to the original sender. Also, a single posting status for all non-member addresses (as above, but with no whitelist option).
Other features of some mailing-list managers: get general info about a list, get the new-member mailing for a list, an option to not include specific members in any visible list of subscribers, search the list archives, change a member's password.
closed -- members can only be added by a list owner (possibly by approving a request made via a web or email interface) and only members can post to the list. Attachments, getting the list of subscribers' addresses, etc. are allowed; abuse should not happen since the list members are all vetted, and any that does occur can be handled by peer pressure or by removing the abuser from the list. Examples would be nesfa-regular<at>nesfa.org, geeks<at>nesfa.org, etc.
'moderated' mailing lists -- the same as 'private' lists except that posts by non-members are forwarded to a list of moderators for approval. [What might we use this for?]
open mailing lists -- anyone can add themselves to the list (subject to a blacklist) and only members can post. An example would be nesfa-open<at>nesfa.org?
open announce-only lists -- anyone can add themselves to the list as read-only, but only a small number of people designated by the list owner can post to it. By default, replies should be directed to some other list. An example would be nesfa-announce<at>nesfa.org.
True mailing lists at BOSKONE.ORG:
Addresses at BOSKONE.ORG which are tied to mailing lists:
Addresses at BOSKONE.ORG which are used to administer the system:
Other addresses at BOSKONE.ORG:
Aliases for addresses at BOSKONE.ORG:
There are a few NESFA.ORG addresses which I know exist but haven't seen mentioned (there may be others):
True mailing lists at NESFA.ORG:
Mailing lists at NESFA.ORG that are really just aliases for a few people (boskone, info, pb are set up as mailing lists to avoid theworld.com's over-aggressive spam filters):
Addresses at NESFA.ORG which are effectively mailing lists?
Addresses at NESFA.ORG which are tied to mailing lists:
Addresses at NESFA.ORG used to administer the system:
Other addresses at NESFA.ORG:
Aliases for addresses at NESFA.ORG: