User Tools

Site Tools


This is an old revision of the document!

Mail and Lists

Wiki page to cover BALUG's email and lists

Migrations to self-hosting

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. migrate off of DreamHost.Com as soon as feasible
  2. make transition as painless as reasonably feasbible

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

Lists - lists are presently on There is also some mail on High-level of migration strategy off of DreamHost.Com (to be implemented as feasible, but we do need to get off of DreamHost.Com):

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

Note also that presently much of BALUG's content is already self-hosted - e.g. [www.] is mostly just rsynced from "master" that's self-hosted; primary traffic can be put to that master with some DNS changes - 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.

List migration step-by-step

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

  • [created]
  • - 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]
  • 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
  • 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 we're not able to get raw mbox format.

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

obscure_addresses (privacy): Show member addresses so they're not directly recognizable as email addresses?

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 settings isn't and wasn't set, and where the email addresses in the archive are obfuscated anyway, seems we don't have a setting we can access to turn off that behavior.

  • for our currently installed 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 (hasn't really been used, but 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).
  • 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                             *:*     
LISTEN     0      10                            *:*     
  • 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 DreamHost.Com email stuff (certainly at least all Internet facing) is 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                             *:*     
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 10800 IN  CNAME 14400 IN PTR
  • 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.
  • send some initial test email messages to the domain - seemed to go relatively okay - at least after the RAM increase noted above - still 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:      14400   IN      AAAA    2001:470:1f04:19e::2
  • did set up BALUG-Test list, fixed some various issues, it seems at least (partially) working, but there are 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 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.

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.,} (and later to add, and eventually drop
o N outbound IPv6 SMTP to TCP port 25 should be open and operational (blocked by the (IPv6) tunnel provider by default,
    (probably) won't be able to get this opened until after is fully migrated off of hosting)
o Y (implemented, need to verify) 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:
    <; ; ; ; ; ; 2000::/3
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]://[whatever] should not redirect to other domains (except in future to
o Y http[s]://[mailman-prefix]/[whatever] should only give out https
o Y http[s]://[mailman-prefix]/[whatever] should only use https: http should redirect to https
o Y http[s]://{,cgi-bin{,/{,mailman{,/}}}} redirect to
o Y (fixed) http[s]:// Disallow: / # will later update more appropriate under domain
o Y full mbox archive publicly available; procedure:
    to file:
    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 ? should be able to completely reload archive, add/drop messages from archive, etc. & document procedure thereof
o Y (working or mostly working?) mailman commands should work via email: subscribe/unsubscribe/help (need more complete list)
o ? (untested) mailman admin commands should work via email (need more complete list)
o (partially staged) should accept legitimate email for legitimate addresses
o N (future) default sending domain of host:
o N (future) add appropriate SPF records for,
o ( staged, remainder pending DNS & SSL cert, etc.) lists should use URLs starting with:
o (MTA partially staged, remainder pending DNS, SSL certs, reconfigurations) lists should use email addresses ending with:
o (requested 2017-08-19, Ticket #7876434) get raw mbox of archives from DreamHost.Com if feasible
o (emailed requested of primary account holder 2017-08-20, reminder sent 2017-08-24 & 2017-08-30; I called and left voicemail message 2017-09-06) above requires DreamHost support ticket opened requesting such from primary account holder
o (pending) DreamHost primary account holder to open support ticket with to get raw archives in mbox format.
o N (future) http[s]:// - set up appropriately
o (staged) http[s]:// - set up appropriately
o (staged) http[s]://[mailman-prefix]/ should only use https
o (staged) http[s]://{,cgi-bin{,/{,mailman{,/}}}} should redirect to
o N (future) all of http[s]:// should 301 redirect to corresponding URLs
o (staged) legacy URLs should 301 redirect to new locations (where different)
o Y http[s]://{temp,www} update to use
o Y http[s]://{temp,www} update to exclude BALUG-Test list
o N (future) http[s]://{lists,temp,www} update to use
o N (future) http[s]://{lists,temp,www} canonicalize to
o ? (future) decommission domain?

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

' 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 away from

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} == "" && %{HTTPS} == "on"
        #Require expr %{SERVER_NAME} in { "", "" } && %{HTTPS} == "on"
        #Require expr %{SERVER_NAME} == "" && %{HTTPS} == "on"
balug/mail_and_lists.1504713459.txt.bz2 · Last modified: 2017-09-06T15:57:39+0000 by michael_paoli