Wiki page to cover BALUG's email and lists

Not an entire history, but most releant as of the time of this writing, BALUG's email and lists are still hosted on DreamHost.Com. For numerous reasons we wish to

1. [done] migrate off of DreamHost.Com as soon as feasible
2. [done] make transition as painless as reasonably feasible

Where those two objectives may conflict, in general the former will take precedence over the latter.

Lists - lists on lists.balug.org. [were, and shall return to] There is also some mail on balug.org. [Migration was fully completed off of DreamHost.com on 2017-09-18] High-level of migration strategy off of DreamHost.Com (to be implemented as feasible, but we do need to get off of DreamHost.Com):

• (done) (temporarily) create temp.balug.org (implemented initially as fully delegated sub-domain)
• (done) create test list (initally on temp.balug.org)
• (done) (initially) migrate lists - from lowest traffic/subscribers first, to highest, from lists.balug.org to temp.balug.org
• (done) fully prepare email infrastructure on @balug.org (e.g. for various aliases there) for migration (and test as feasible, etc.)
• (done - all relevant data copied) copy/migrate any remnant bits from DreamHost.Com if/as feasible
• (done) pull the plug on DreamHost.Com (remove DNS delegation from it), move forward to cancel any relevant DreamHost.Com account(s) or services thereof (relevant notification(s) sent)
• (done) temp.balug.org is intended to be temporary - transitional - it will be migrated back to lists.balug.org (once we're done with DreamHost.Com and we can make that self-hosted), then we'll slowly phase out temp.balug.org (for some fair while we'll allow both to work, but lists.balug.org will be the canonical).

Note also that much of BALUG's content (was) is already self-hosted (now is) - e.g. [www.]balug.org (was) is mostly just rsynced from "master" that's self-hosted; primary traffic can be put to that master with some DNS changes (done) - when that and anything else that needs/ought be migrated/pulled from DreamHost.Com is done, then it's safe to pull/cut the cord / flip the switch, and move off of DreamHost.Com (done).

(Work-in-progress, and may be mostly documented as we go along the way)

• temp.balug.org [created, moved to, moved from and deprecated, phased out, done]
• temp.balug.org - any DNS records we need to create/add there? - notably not only what we need but implement as soon as feasible to avoid any DNS negative caching TTL issues [checked, done, more than sufficient … phased out … done]
• archives - will want to get raw mbox of archives from DreamHost.Com if feasible, next best get rawest forms we can manage to get of archives [done]
• disable any email obfuscation of archives [checked and adjusted as feasible] - that may/will slightly aid quality of archive bits we can get - especially if/where we're not able to get raw mbox format and/or complete history thereof.
  

checked lists, BALUG-Talk and BALUG-Admin lists:

obscure_addresses (privacy): Show member addresses so they're not directly recognizable as email addresses? [done - at least as feasible]

Setting this option causes member email addresses to be transformed when they are presented on list web pages (both in text and as links), so they're not trivially recognizable as email addresses. The intention is to prevent the addresses from being snarfed up by automated web scanners for use by spammers.

changed from Yes to No (BALUG-Announce was already set to No).
From walking the admin menus, the above seems the only setting of relevance to unobfuscate email addresses, but since they're obfuscated on the BALUG-Announce list, where that setting isn't and wasn't set, and where the email addresses in the archive are obfuscated anyway, seems we didn't (on DreamHost) have a setting we could access to turn off that behavior.

• for our at migration time target operating system (Debian GNU/Linux 8.8 (jessie) amd64) to work with our desired anti-spam software/configuration, we'll want package exim4-daemon-heavy - have that installed, but need to more suitably configure that ([done] hadn't really been used, was installed initially with very low setting on priority of questions asked when installed, probably not so close to default - we want (much) closer to default for baseline/reference before we start integrating the other pieces [done - reinstalled very near to defaults, then adjusted suitably from there]).
• So, for clean reinstall of exim4-daemon-heavy, temporarily installed another (conflicting) MTA (sendmail) and purged the exim4 packages, then purged the sendmail packages and reinstalled the exim4 packages thusly for a nice clean base install:
  

# (umask 022 && DEBIAN_PRIORITY=critical DEBIAN_FRONTEND=noninteractive apt-get -y --purge install exim4-daemon-heavy exim4-doc-\* sendmail\*-)

• And we check that it's not (yet) listening to The Internet - have some serious anti-spam and other configuration bits to do before that … and the listening looks fine for now:
  

$ ss -nlt '( sport = :25 or sport = :587 )'
State      Recv-Q Send-Q        Local Address:Port          Peer Address:Port 
LISTEN     0      10                127.0.0.1:25                       *:*     
LISTEN     0      10                127.0.0.1:587                      *:*     
$ 

• We also notice it's not listening at all on IPv6 (not even \[::1\]:25, \[::1\]:587). That's perfectly fine … at least for now, as …
• One or our existing key present design/migration criteria is: "not worse than" - notably not worse than existing configuration/functionality - and the existing(/former) DreamHost.Com email stuff (certainly at least all Internet facing) is(was) purely IPv4 - with no IPv6 at all … so we're perfectly fine with enabling IPv6 later at our leisure (certainly ought be done … but no extreme rush for that part).
• Turns out our former MTA wasn't fully cleaned out - was unlinked but still running, SIGTERMed it, started exim, and rechecked our listening IPs for our ports:
  

$ ss -nlt '( sport = :25 or sport = :587 )'
  State      Recv-Q Send-Q        Local Address:Port          Peer Address:Port 
LISTEN     0      20                127.0.0.1:25                       *:*     
LISTEN     0      20                      ::1:25                      :::*  
$ 

• that looks fine - also tested simple local mail - appears OK
• also installed: sa-exim (probably needed, and dependencies thereof)
• also installed: clamav and libclamunrar7 (and dependencies thereof) - probably not required, but if the resource consumption isn't too great, very possibly a "good to have" - notably help us from being a (mostly immune) carrier.
• also added additional "reverse" DNS for temp.balug.org. (later also added lists.balug.org., temp.balug.org. will yet later be phased out):

238.194.144.198.in-addr.arpa. 10800 IN  CNAME   238.net232.194.144.198.in-addr.arpa.
238.net232.194.144.198.in-addr.arpa. 14400 IN PTR temp.balug.org.

• after much more configuration of eximconfig, exim4, and some adding of packages and further configuration also including clamav and spamassassin and spfd and related, got to semi-working configuration …
• also, clamav quite the (virtual) memory resource hog … increased the host (virtual machine) RAM up from 512 MiB to 1 GiB - that seems sufficient for at least present - but clamav still consumes over 50% of RAM much of the time. At 512 MiB of system RAM, the OOM killer was kicking in (later made some additional adjustments to prevent Apache RAM consumption from ballooning too big and triggering OOM killer).
• sent some initial test email messages to the domain - seemed to go relatively okay - at least after the RAM increase noted above - still (was) much to (better) configure/optimize, but may be "good enough" for reasonable start, and first (test) list, etc … still need to install and configure list software.
• added AAAA record for our MX - not really any great reason not to at this point:

mx.temp.balug.org.      14400   IN      AAAA    2001:470:1f04:19e::2

• did set up BALUG-Test list, fixed some various issues, it seems it was at least (partially) working, but there are(were) still various issues to correct and address, more to configure, etc. - but was at least able to successfully subscribe a non-local email address to it … but (was) still much more to do (and test).
• should probably create a bullet list of stuff to test on (test) list and confirm it's all working (sort'a like a set of regression tests) - a small bit of which has already been addressed/corrected (did create list, tested, etc.).

email/List stuff to (re)test - results (Y - good, N - failed, ? - to be tested)

o Y? (partially fixed?) greylisting: shouldn't cause excessive delays
o Y? (partially fixed?) greylisting: shouldn't cause false permanent blocks
o Y flood protection: enable and reasonably reject spam floods
o Y? (partially fixed?) flood protection: when enabled, shouldn't cause excessive delays
o Y? (partially fixed?) flood protection: when enabled, shouldn't cause false permanent blocks
o N don't reject empty body (e.g. legitimate mailman command in subject with empty body)
o Y If rejecting empty body, implement work-around (suitable updates to texts, etc.)
o Y SMTP TLS - should use STARTTLS on sending when available
o Y (fixed) SMTP TLS - should offer working STARTTLS on receiving with CA signed cert for applicable domain(s)
o Y SMTP TLS - set up separate cert for MTA to have read access to private key with just {temp.,}balug.org (and later to add lists.balug.org, and eventually drop temp.balug.org)
o Y [requested 2017-09-17, granted and made open 2017-09-18] outbound IPv6 SMTP to TCP port 25 should be open (blocked by the (IPv6) tunnel provider by default)
o Y outbound IPv6 SMTP to TCP port 25 should be made fully operational for MTA & configurations thereof
o N/A (was earlier implemented as work-around and verified) if outbound IPv6 SMTP to TCP port 25 is not open, apply workaround:
    changed config line in /etc/exim4/eximconfig/config/ignore_target_hosts to:
    <; 127.0.0.1/8 ; 0.0.0.0/32 ; 192.168.0.0/16 ; 172.16.0.0/12 ; 10.0.0.0/8 ; 2000::/3
    and when no longer applicable, set it to:
    <; 127.0.0.1/8 ; 0.0.0.0/32 ; 192.168.0.0/16 ; 172.16.0.0/12 ; 10.0.0.0/8
    The above not quite matching the original, but much more friendly for including any IPv6
o Y relevant list user URLs should generally work: info/subscribe/unsubscribe/archive (need more complete list)
o Y relevant list admin URLs should generally work: per-list and overall admin, roster, etc. (need more complete list)
o Y http[s]://temp.balug.org/[whatever] should not redirect to other domains (except in future to lists.balug.org)
o Y http[s]://temp.balug.org/[mailman-prefix]/[whatever] should only give out https
o Y http[s]://temp.balug.org/[mailman-prefix]/[whatever] should only use https: http should redirect to https
o Y http[s]://temp.balug.org/{,cgi-bin{,/{,mailman{,/}}}} redirect to https://temp.balug.org/cgi-bin/mailman/listinfo
o Y (fixed) http[s]://temp.balug.org/robots.txt Disallow: / # will later update more appropriate under lists.balug.org domain
o Y full mbox archive publicly available; procedure:
    add:
    PUBLIC_MBOX = Yes
    to file:
    /etc/mailman/mm_cfg.py
    restart mailman
    for existing lists, toggling archive from public to private and back again seems sufficient to then create the needed link
o N full mbox archive should be publicly available via public rsync
o Y should be able to completely reload archive, add/drop messages from archive, etc. & document procedure thereof (basically uses mailman command arch, with --wipe option, and run it as id list)
o Y (working or mostly working?) mailman commands should work via email: subscribe/unsubscribe/help (need more complete list)
o Y (untested) mailman admin commands should work via email (need more complete list)
o Y should accept legitimate email for legitimate @balug.org addresses
o Y default sending domain of host: @balug.org (for non-list email, list email updated to use @lists.balug.org)
o Y add/update appropriate SPF records for @lists.balug.org, @balug.org, @temp.balug.org
o Y lists should use URLs starting with: https://lists.balug.org/
o Y lists should use email addresses ending with: @lists.balug.org
o Y get raw mbox of archives from DreamHost.Com (completed 2017-09-16)
o Y (emailed request of primary account holder 2017-08-20, reminder sent 2017-08-24 & 2017-08-30; I called and left voicemail message 2017-09-06; 2017-09-13: called and left voicemail again, sent email again, also sent cellular text message; 2017-09-14 called and left voicemail again and sent email again also gave additional option to have primary user transfer DreamHost primary user and billing to Michael Paoli; 2017-09-16: Dreamhost primary user opened ticket with DreamHost, DreamHost made the files available to us, I transferred files from DreamHost and ran sanity checks on the files (appears to be good set of the expected data)) above requires DreamHost support ticket opened requesting such from primary account holder
o Y DreamHost primary account holder to open support ticket with DreamHost.com to get raw archives in mbox format (done 2017-09-16).
o Y http[s]://temp.balug.org/robots.txt - set up appropriately
o Y http[s]://lists.balug.org/robots.txt - set up appropriately
o Y http[s]://lists.balug.org/[mailman-prefix]/ should only use https (redirect http to https)
o Y http[s]://lists.balug.org/{,cgi-bin{,/{,mailman{,/}}}} should redirect to https://lists.balug.org/cgi-bin/mailman/listinfo
o Y all of http[s]://temp.balug.org/ should permanent (301) redirect to corresponding https://lists.balug.org/ URLs
o Y legacy http://lists.balug.org URLs should 301 redirect to new locations (where different)
o [superceded] http[s]://{temp,www}.balug.org/lists/balug-announce-do-not-auto-add.html update to use temp.balug.org
o Y http[s]://{temp,www}.balug.org/lists/balug-announce-do-not-auto-add.html update to exclude BALUG-Test list
o Y http[s]://{lists,temp,www}.balug.org/lists/balug-announce-do-not-auto-add.html update to use lists.balug.org
o Y http[s]://{lists,temp,www}.balug.org/lists/balug-announce-do-not-auto-add.html canonicalize to http[s]://lists.balug.org/lists/balug-announce-do-not-auto-add.html
o ? http://www.balug.org/lists/balug-announce-do-not-auto-add.html - redirect to https? (all the others above go to https)
o Y decommission temp.balug.org domain
o Y add IPv6 to {www.,lists.,}balug.org
o [partially done] review/fix/verify Mailman mailman-loop and other Mailman lists bounce processing
o [future] Mailman - review/use/configure VERP - for better bounce/backscatter processing/identification
o Y add DNSSEC for balug.org.

per member configuration (options) and transfer thereof (as feasible)
Mailman stores the data in a Python pickle (.pck) format per-list file.
Have written program that scrapes the web pages, and gathers almost all that data of relevance.
That essentially gives us everything except: passwords So … that's probably darn good enough overall.
Format - as various /usr/lib/mailman/bin/dumpdb shows us for output (dump) we have essentially this, and likely need to have massage the data to quite similar form to load(/edit) it into Python pickle data to adjust user configurations. For most of the options, they're in a binary format (yes/no or on/off, etc.), and Python use a power of 2 weighting of each and combines them into a single decimal number. Here's the basic high-level of that data and the binary weightings and also the format of how strings are stored/represented (likely Phython convention):

'members': { 'canonical_lowercase_email': 'case_preserved_email', 'canonical_lowercase_email': 0 (0 when user entered without uppercase), ... }
'usernames': { 'canonical_lowercase_email': u'Your name (optional)' (empty string if not set), ... }
disablemail: delivery_status (2, epoch_timestamp_to_6_points_after_decimal)
digest: digest_members vs. members
mime          8     +8 Plain
dontreceive   2     +2 receive own: No
ackposts      4     +4 receive ack: Yes
remind       32    +32 reminder: No
conceal      16    +16 Conceal: Yes
rcvtopic     64    +64 receive messages that do not match: Yes
nodupes     256   +256 avoid duplicates: Yes

strings:
' quoted
\' for '
\\ for \

Fix for: Show case preserved emails in the roster (to be considered and possibly tested/applied).

Added rewrite rules to remap old URLs to new - this will be useful most notably once we're hosting lists.balug.org away from DreamHost.com (done):

RewriteRule "^/*listinfo\.cgi/*$" https://%0/cgi-bin/mailman/listinfo [L,R=permanent]
RewriteRule "^/*listinfo\.cgi/+(balug-(?:announce|talk|admin))-balug\.org$" "https://%0/cgi-bin/mailman/listinfo/$1" [L,R=permanent]
RewriteRule "^/*pipermail/(balug-(?:announce|talk|admin))-balug\.org/(.*)$" "https://%0/pipermail/$1/$2" [L,R=permanent]
RewriteRule "^/*admin\.cgi/(balug-(?:announce|talk|admin))-balug\.org$" "https://%0/cgi-bin/mailman/admin/$1" [L,R=permanent]
RewriteRule "^/*roster\.cgi/(balug-(?:announce|talk|admin))-balug\.org$" "https://%0/cgi-bin/mailman/roster/$1" [L,R=permanent]

Added constraints to deny mailman cgi except for the correct vhost(s) using HTTPS:

<Directory "/usr/lib/cgi-bin/mailman/">
        Require expr %{SERVER_NAME} == "temp.balug.org" && %{HTTPS} == "on"
        #Require expr %{SERVER_NAME} in { "lists.balug.org", "temp.balug.org" } && %{HTTPS} == "on"
        #Require expr %{SERVER_NAME} == "lists.balug.org" && %{HTTPS} == "on"
</Directory>

(and that's had lists.balug.org enabled, and temp.balug.org has been phased out) added mailman-loop alias - this may not be optimal handling, but the alias needs to exist (needs to always be deliverable), and is probably at least "good enough" for now:

mailman-loop: postmaster