Mail

Note! This page mostly discusses the new configuration which is not active yet! See #Old Wikimedia email setup for the system currently in place.

Design decisions

Black box mail system, no user shell logins 

Few users would make good use of this anyway. Greatly simplifies network and host security, allows the use of some (non-critical) non-standardized extensions between software components for greater performance, interoperability and features because it doesn't have to support whatever shell users might install to access things directly.

IMAP only, no POP3 

IMAP has good client support nowadays, and for a large part solves the problem of having multiple clients. Also backups can be done centrally on the server side, and multiple folders with server side mail filtering might be supported.

Support for mail submission 

Through SMTP authentication we can allow our users to submit mails through the mail server, without them having to configure an outgoing mail server for whatever network they reside on. Can support multiple ports/protocols to evade firewalls.

SSL/TLS access only, no plain-text 

Although client support for this is not 100% yet, especially on mobile devices, the risks of using plain-text protocols is too high, especially with users visiting conferences and other locations with insecure wireless networks.

Quota support 

Although we can set quotas widely especially for those who need it, quotas should be implemented to protect the system.

Spam and virus filtering 

Is unfortunately necessary. Whether this should be global or per-user is to be determined.

Multi-domain support 

We have many domains, and the mail setup should be able to distinguish between domains where necessary.

Web access 

Some form of web-mail would be nice, although not critical at first and can be implemented at later stages.

Backups 

At least daily, with snapshots.

Cold failover 

Setting up a completely redundant system is probably a bit overkill at this stage, but we should make it easy and quick to set up a new mail system on other hardware in case of major breakage.

Documentation 

Although not all aspects of the involved software can be described of course, the specifics of the Wikimedia setup should be properly documented and HOWTOs for commonly needed tasks should be provided.

Software

MTA

Exim : Great flexibility, very configurable, reliable, secure.

IMAP server

Dovecot : Fast, secure, flexible.

Formats used

Maildir 

Safe, convenient format, moderately good performance, good software support.

Password and user databases 

To be determined. Important aspects: easy maintenance, good software support, replication support. Possible options:

• passwd-file - Simple field-separated text file, non-indexed. Supported by both Exim and Dovecot.
• sqlite - Indexed file format, powerful SQL queries, no full-blown RDBMS needed. Also easy to change to MySQL/PostgreSQL should that ever be necessary. Supported by both Exim and Dovecot.

Other data lookups 

either flat-file for small lists, or cdb for larger, indexed lookups.

Mailbox storage and mail delivery

Ext3 as file system 

ReiserFS may be a bit faster, but Ext3 is more reliable. Make sure directory indexes are enabled.

LVM 

For easy resizing, moving of data to other disks, and snapshots for backups.

RAID-1 

The new mail servers have hardware RAID controllers, we'll probably use them.

Dovecot's "deliver" as LDA 

Though Exim has a good internal Maildir "transport", the use of Dovecot's LDA allows it to use and update the Dovecot specific indexing for greater performance.

fcntl() and dot-file locking 

Greatest common divisors.

Maildir++ quotas 

Standard, reasonably fast.

Authentication

PLAIN authentication 

Universally supported for both IMAP and SMTP. Encrypted connections are used exclusively, so no elaborate hashing schemes needed.

SMD5 or SSHA password scheme 

Salted hashing.

SMTP authentication through either Exim's Dovecot authenticator, or using direct lookups 

Exim 4.64 has support for directly authenticating against Dovecot's authenticator processes, though this version is not in Ubuntu Feisty yet, so needs backporting. If direct lookups from Exim's authenticators are easy enough, use that. Also depends on the security model.

Layout

The mail setup consists of 2 general mail servers, plus a mailing lists server (lily) and an OTRS server. The two general mail servers are mchenry and sanger.

Wikimedia mail setup

One server (mchenry) acts as relay; it accepts mail connections from outside, checks them for spam, viruses and other policy checks, and then queues and/or forwards to the appropriate internal mail server. It also accepts mail destined for outside domains from internal servers, including the application servers.

The other server, sanger, is the IMAP server. It accepts mail from mchenry and delivers it to local user mailboxes. Outgoing mail from SMTP authenticated accounts are also accepted on this server, and forwarded to mchenry, where it's queued and sent out. Web mail and other supportive applications related to user mail accounts and their administration will also run on sanger.

Lily, the mailing lists server, also acts as a secondary MX and forwards non-mailing list mail to mchenry. In case of downtime of mchenry, it might be able to send partial (IMAP account) mail to sanger directly, depending on the added complexity of the configuration. During major hardware failure of sanger, mchenry (with identical hardware) should be able to be setup as IMAP server.

Configuration details

Mail relay

The current mail relay is mchenry.

mchenry uses Exim 4, the standard Ubuntu Feisty exim4 exim4-daemon-heavy package. This package does some stupid things like running under a Debian-exim user, but not enough to warrant running our own modified version. All configuration lives in /etc/exim4, where exim4.conf is Exim's main configuration file.

The following domain and host lists are defined near the top of the configuration file:

# Standard lists
hostlist wikimedia_nets = <; 66.230.200.0/24 ; 145.97.39.128/26 ; 211.115.107.128/26 ; 2001:610:672::/64
domainlist system_domains = @
domainlist relay_domains =
domainlist legacy_mailman_domains = wikimedia.org : wikipedia.org

domainlist local_domains = +system_domains : +legacy_mailman_domains : lsearch;CONFDIR/local_domains

system_domains is a list for domains related to the functioning of the local system, e.g. mchenry.wikimedia.org and associated system users. It has little relevance to the rest of the Wikimedia mail setup, but makes sure that mail submitted by local software is handled properly.

relay_domains is a list for domains that are allowed to be relayed through this host.

local_domains is a compound list of all domains that are in some way processed locally. They are not routed using the standard dnslookup router.

For content scanning, temporary mbox files are written to /var/spool/exim4/scan, and deleted after scanning. To improve performance somewhat, this directory is mounted as a tmpfs filesystem, using the following line in /etc/fstab:

tmpfs   /var/spool/exim4/scan   tmpfs   defaults        0       0

Aliases

Each Wikimedia domain (wikimedia.org, wikipedia.org, wiktionary.org, etc...) is now distinct and has its own aliases file, under /etc/exim4/aliases/. Alias files use the standard format. Unqualified address targets in the alias file (local parts without domain) are qualified to the same domain. Special :fail: and :defer: targets and pipe commands are also supported, see http://www.exim.org/exim-html-4.66/doc/html/spec_html/ch22.html#SECTspecitredli.

The following router takes care of this. It's run for all domains in the +local_domains domain list defined near the top of the Exim configuration file:

domainlist local_domains = +system_domains : +legacy_mailman_domains

It checks whether the file /etc/exim4/aliases/$domain exists, and then uses it to do an alias lookup.

# Use alias files /etc/exim4/aliases/$domain for domains like
# wikimedia.org, wikipedia.org, wiktionary.org etc.

aliases:
       driver = redirect
       domains = +local_domains
       require_files = CONFDIR/aliases/$domain
       data = ${lookup{$local_part}lsearch{CONFDIR/aliases/$domain}}
       qualify_preserve_domain
       allow_fail
       allow_defer
       forbid_file
       include_directory = CONFDIR
       pipe_transport = address_pipe
       cannot_route_message = Address unknown

OTRS

For OTRS, the mail relay queries the OTRS MySQL servers directly to check the existence of an OTRS mail address. This implies that newly created OTRS queues / mail addresses will start to work immediately and no involvement from Wikimedia admins is needed.

The MySQL servers are specified near the top of the Exim configuration file:

# MySQL lookups (OTRS)
hide mysql_servers = srv7.wikimedia.org/otrs/exim/password : \
                     srv8.wikimedia.org/otrs/exim/password

These servers will be queried in turn. If neither of these servers respond, or respond with an error, the mail will be deferred. A MySQL user account "exim" with (just) SELECT privileges on the system_address table of the otrs database needs to exist, which is accessible from the mail relay (mchenry.wikimedia.org).

The following router does the actual aliasing of the OTRS address to otrs@ticket.wikimedia.org, if the OTRS queue address exists in the database:

# Query the OTRS MySQL server(s) for the existence of the queue address
# $local_part@$domain, and alias to otrs@ticket.wikimedia.org if
# successful.

otrs:
       driver = redirect
       domains = +local_domains
       condition = ${lookup mysql{SELECT value0 FROM system_address WHERE value0='${quote_mysql:$local_part@$domain}'}{true}fail}
       data = otrs@ticket.wikimedia.org

SpamAssassin

SpamAssassin is installed using the default Ubuntu spamassassin package. A couple of configuration changes were made.

By default, spamd, if enabled, runs as root. To change this:

# adduser --system --home /var/lock/spamassassin --group --disabled-password --disabled-login spamd

The following settings were modified in /etc/default/spamassassin:

# Change to one to enable spamd
ENABLED=1

User preferences are disabled, spamd listens on the loopback interface only, and runs as user/group spamd:

OPTIONS="--max-children 5 --nouser-config --listen-ip=127.0.0.1 -u spamd -g spamd"

Run spamd with nice level 10:

# Set nice level of spamd
NICE="--nicelevel 10"

In Exim, SpamAssassin is called from the DATA ACL for domains in domain list spamassassin_domains. exim4.conf:

domainlist spamassassin_domains = *

acl_smtp_data = acl_check_data

acl_check_data:
        # Let's trust local senders to not send out spam
        accept hosts = +relay_from_hosts

        # Run through spamassassin
        accept endpass
               acl = spamassassin

spamassassin:

        # Only run through SpamAssassin if requested for this domain and
        # the message is not too large
        accept ! domains = +spamassassin_domains
        accept condition = ${if >{$message_size}{40K}}

        # Add spam headers if score >= 1
        warn spam = nonexistent:true
             condition = ${if >{$spam_score_int}{10}{1}{0}}
             add_header = X-Spam-Score: $spam_score ($spam_bar)
             add_header = X-Spam-Report: $spam_report

        # Reject spam at high scores (> 12)
        deny message = This message scored $spam_score spam points.
             spam = nonexistent/defer_ok
             condition = ${if >{$spam_score_int}{120}{1}{0}}

        accept

First, not listed in spamassassin_domains is accepted, as well as mails bigger than 40 KB. Then a Spam check is done using the local spamd daemons. If that results in a score of minimum 1, X-Spam-Score: and X-Spam-Report: headers are added. If the spam score is 12 or higher, the mail is rejected outright.

Mailing lists

Mailing lists now live on a dedicated mailing lists server (lily) on a dedicated mail domain lists.wikimedia.org. However, mail for the old addresses such as info-en@wikipedia.org still come in and should be rewritten to the new addresses, and then forwarded to the mailing lists server.

Near the top of the Exim configuration file a domain list is defined, which contains mail domains that can contain these old addresses:

domainlist legacy_mailman_domains = wikimedia.org : wikipedia.org

The following router, near the end of the routers section, checks if a given local part exists in the file /etc/exim4/legacy_mailing_lists, and rewrites it to the new address if it does, to be routed via the normal DNS MX/SMTP routers/transports. Since Mailman does not distinguish between domains, only a single local parts file for all legacy mailman domains exists. This file only needs to contain the mailing list names; all suffixes are handled by the router.

# Alias old mailing list addresses to @lists.wikimedia.org on lily

legacy_mailing_lists:
       driver = redirect
       domains = +legacy_mailman_domains
       data = $local_part$local_part_suffix@lists.wikimedia.org
       local_parts = lsearch;CONFDIR/legacy_mailing_lists
       local_part_suffix = -bounces : -bounces+* : \
                               -confirm+* : -join : -leave : \
                               -owner : -request : -admin : \
                               -subscribe : -unsubscribe
       local_part_suffix_optional

Old Wikimedia email setup

• postfix, mailman, OTRS, spamassassin on goeje
  • mail.wikimedia.org <- service ip/name for mail
  • secure.wikimedia.org <- service ip/name for OTRS
  • ticket.wikimedia.org <- service name for OTRS, redirects to secure.wikimedia.org currently
• sendmail on most other machines (apaches)
  • internally in pmtpa they forward to smtp.pmtpa.wmnet, which relays to the external world.

How to make an email alias

On goeje:

vi /etc/postfix/aliases
newaliases
postfix reload

It takes up to 15 minutes until the secondary MXes accept mail for new aliases.

See also

• Mailing lists for the setup of the mailing lists server.

External documentation

• The Exim website and wiki
• The Dovecot website and wiki