[PLUG] Strawman proposal: common mailing list infrastructure for LUGs

[Rich Kulawiec <rsk@gsp.org>]

(I started a new thread because it looks like/sounds like the PLUG
mailing list hosting issue is probably resolved.)

This follows on a comment that I made (and that some others responded to)
in the course of the PLUG mailing list discussion.  This is a set of
hasty, incorrect, obscure, etc., notes on what a design for a mailing
list system for all LUGs might look like.   I think there could be
a major win here, because as things are now, there are a lot of people
doing a lot of overlapping work, and there are a lot of LUGs using
really outdated software (with accompanying impact on performance,
security, etc.).  This *does* come with technical problems, however
nearly all of these are well-known and well-understood, so that's
probably not the roadblock.

The roadblock (as it is so often) is people.  Getting everyone on
the same page won't be easy.  And just like there are people using
outdated code, there are people using outdated practices...and
getting them to let go will require persuasion and maybe bourbon.

But let me shaddup about that and give you the strawman in bullet
point form:

Live server plus identical hot spare.  Rsync of /var/local/mailman
	at least once every 24 hours, maybe every 6? 4?  Hot spare
	needs to be somewhere else, geographically/ASN-wise.

Manual cutover.  (Automatic cutover isn't necessary and it's too risky)
	Cutover procedure tested pre-production.  Cutover used as
	necessary for things like OS upgrades.  (This will shake out
	any bugs in the procedure periodically.)

Mailman 2.x now, probably Mailman 3.x later

Insert argument about Linux vs. BSD, sendmail vs. postfix,
	BIND vs. unbound, Apache vs. nginx, etc.

Minimal OS install.  Basic OS plus servers for DNS, HTTP, SMTP, SSH.
	Turn off everything that's not needed.  Better: don't install it.
	Separate partitions for root, usr, var, etc.

OS configuration minimized.  DNS server configured to allow recursive
	queries from localhost only, given fairly large cache.
	HTTP server with as many features as possible turned off.
	SSH access only allowed from geographic regions where necessary.

Insert argument about physical vs. virtual servers.  Complicate with
	argument about CPU architecture.

List configuration under revision control.  RCS will suffice but
	more people know subversion/git now.  List configurations
	as cookie-cuttered as possible to minimize surprises and
	ease maintenance.  Consistify list naming as much as possible,
	e.g., yourlug-announce, yourlug-discuss, yourlug-jobs.

Standardize list hostnames across LUGs, e.g. lists.example.org.
	Make sure list traffic separated from other LUG traffic.

Make sure -owner/owner- aliases go to the right people.  Set up
	mailing list for all-the-people-at-all-the-LUGS-who-deal-with-lists,
	sync it with this.

Change control procedures so that nobody breaks the MTA at 3 AM
	when nobody else knows.  All configuration documented.  No whining
	about doing documentation.

Minimum of three DNS servers on minimum of two different ASNs.  Set TTL
	so that cutover to hot spare is feasible in reasonable time.

Full support for RFC 2142 role addresses, e.g., "postmaster", abuse".
	These should connect to private mailing lists so that archives
	are automagically created.

Make sure the host uses NTP correctly.

Insert argument about common standards for email netiquette.  Take
	guidance from "Miss Mailers Answers Your Questions
	on Mailing Lists" ;)

List configuration tailored for Linux-ish content, e.g., suitable
	size limits, MIME attachment support, etc.

DMARC mitigation.  Sigh.  ARC, when it's ready for prime time.

Liason with big four gorillas to pre-empt some mail acceptance issues.

Minimum of three people handling postmaster/abuse/hostmaster/webmaster.
	Simple procedures in place to avoid overlapping work.

Make sure the network the host is on complies with BCP 38.

Backups every 24 hours.  That means backups, not copies.  (Dump makes
	backups.  Rsync makes copies.)  Backups stashed somewhere else.

Retain Mailman logs forever.  (They're not that big.)  Retain all
	messages to -request, -owner, etc., forever.  (Also not that big.)
	Retain all replies to...you get the idea.

Size guesstimation: figure 150 mailing lists averaging 150 people each.
	10 years of traffic each, at 250M for the mbox, 750M for the
	expanded archive.  Thus 150G for archives.  This is probably
	an overestimate by a factor of 3-5.  Point is that all of this
	will fit comfortably on $100 worth of disk with room to grow.

Standard anti-abuse measures: Spamhaus DROP/EDROP, enforce DNS/rDNS
	match, use "greetpause", "Xen" DNSBL, support local domain
	and LHS and network allocation blocks, maybe graylisting, etc.

Avoid VERPing unless really really necessary.  "You are finite.
	 Zathras is finite.  This is wrong tool."

Create "umbrella" list to notify subscribers of all lists of changes.
	Set expectations appropriately: email is not instant messaging
	and doesn't need to be THAT fast.

Set up DMCA compliance process.  (Resist temptation to just
	send back "pound sand".)  Register per 512(c).

Do NOT obfuscate email addresses: it stopped being even marginally
	useful in 2002.   Insert spamtrap addresses to catch at
	least some harvesters, and name/shame them if they abuse
	subscribers.

Implement RFC 2919 (which Mailman does anyway).

Insert argument about policies for problem subscribers.

RFC 2369 headers throughout.  Subject-line tags off by default
	and discouraged (but subscribers can switch them on).
	Standardize message footers.

Cause rejects/bounces to be sent to list owners and to be copied
	to a read-only keep-forever mbox.  (Enables diagnosis of
	issues that cross users, lists, and time.)  Monitor
	this mbox and quash problems pre-emptively when possible.

---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug