[LabFrontPage] [TitleIndex] [WordIndex] 

Information about our mail services

As our main mail services, we provide SMTP (via [http://www.exim.org/ Exim]), IMAP (via [http://cyrusimap.org/ Cyrus]), and mailing lists (via [http://www.list.org/ Mailman]).

Notes on Migration to a full Zimbra Solution

We plan to migrate our mail services to the Zimbra groupware of the University, so that we can shut down local mail handling in the near future. As a preliminary step, we have deactivated the local delivery of mails. The Cyrus IMAP server is still running and accessible via the deprecated SquirrelMail Webfrontend if the the local mailboxes require inspection:

Accessiblity of the SMTP port

Due to the HIZ firewalling rules, port 25 (SMTP) is not accesible from outside the university network. Knowing this, our mail server is configured to accept all mails on port 25 without authentication. [TODO: why is this necessary?].

But if port 25 is blocked, how are emails from the outside getting to the mail server? The MX record for the ps.uni-saarland.de domain looks like this: 

ps.uni-saarland.de.     86341   IN      MX      10 mail.ps.uni-saarland.de.
ps.uni-saarland.de.     86341   IN      MX      20 mail.cs.uni-saarland.de.
ps.uni-saarland.de.     86341   IN      MX      30 mail.uni-saarland.de.

So whenever an external mail server tries to send a mail to a ps.uni-saarland.de domain, it first tries mail.ps.uni-saarland.de. It will then fail due to the firewalling rule. It then tries the next best mail server, namely mail.cs.uni-saarland.de. This server is reachable, so it takes the mail. When this server wants to relay this email to us, it looks up the MX record again [TODO: maybe it "knows" our server is responsible for handling our mail without asking the DNS, but I doubt it]. As an university server, it can access port 25 of our server, so it succesfully delivers the mail.

The Mail Transfer Agent (Exim)

Best Practices when Administrating the Mail Server

It is of paramount importance not to lose any email! Email has a responsibility principle built in, i.e. if and only if you accept the email you are responsible for it. The first step thus always should be to shut down exim. After editing the configuration, run the update-exim4.conf command to rebuild the configuration file. Now, try testing the service without starting the server, if possible. It is useful to do a sendmail -bt <mailaddress> (address testing mode) first to check whether forwards etc. work correctly. Now it's time to start exim again. Send an email to your fellow administrator (or yourself) to check that email actually works. Also observe if you get the usual emails (logcheck, update reports etc.). It has already happened that only local mail worked or vice versa.

Configuration Details

Our local Exim installation takes care of routing of mail for two domains: ps.uni-saarland.de (the default mail domain) and mozart-oz.org. Mail for any other domain is sent to our smarthost, mail.cs.uni-saarland.de. To change this general behaviour, call dpkg-reconfigure on the exim4-config package.

Exim comes with an extensive suite of documentation that should answer most of your questions concerning its configuration. In our location installation, Exim's configuration file is generated from a set of smaller files (below /etc/exim4/conf.d/) by the help of the update-exim4.conf command. (Note that Exim reloads its configuration every time its action is required; therefore, there is no need to restart the daemon after re-building the configuration.)

Here is a list of files added to conf.d for our local mail setup:

IMAP Server (Cyrus)

Accounts and authentication

In case you wonder how cyrus gets to know about new users: cyrus accounts are managed through GOsa; cyrus authentication happens through the saslauthd daemon, which uses PAM passwords. These are the relevant settings in /etc/imapd.conf: 

# Force PLAIN/LOGIN authentication only
# (you need to uncomment this if you are not using an auxprop-based SASL
# mechanism.  saslauthd users, that means you!). And pay attention to
# sasl_minimum_layer and allowapop below, too.
sasl_mech_list: PLAIN

# The mechanism(s) used by the server to verify plaintext passwords. Possible
# values are "saslauthd", "auxprop", "pwcheck" and "alwaystrue".  They
# are tried in order, you can specify more than one, separated by spaces.
#
# Do note that, since sasl will be run as user cyrus, you may have a lot of
# trouble to set this up right.
sasl_pwcheck_method: saslauthd

SSL Encryption

As referenced in /etc/imapd.conf the keypair is expected in the following places: 

tls_cert_file: /etc/ssl/certs/mail.ps.uni-saarland.de.crt
[..]
tls_key_file: /etc/ssl/private/mail.ps.uni-saarland.de.key

To keep track of the keys there's a CA in /root/ca where you can follow the following step to make a new (self-signed) Certificate

  1. /usr/lib/ssl/misc/CA.pl -newreq

    • . to create a new Certification Request. Use the following Values:
      • Country Name (2 letter code): DE
      • State or Province Name (full name): Saarland
      • Locality Name (eg, city): Saarbrucken
      • Organization Name (eg, company): Saarland University
      • Organizational Unit Name (eg, section): Programming Systems Lab
      • Common Name (eg, YOUR name): mail.ps.uni-saarland.de

      • Email Address: kuhlmann@ps.uni-saarland.de

  2. /usr/lib/ssl/misc/CA.pl -sign

    • . To sign this request. If it fails with the error message 'TXT_DB error number 2' the you need to revoke the old key first, by finding out it's index (see demoCA/index.txt) and calling openssl ca -revoke demoCA/newcerts/??.pem to actually revoke it.

  3. {{{openssl rsa -in newkey.pem -out newcert.key

openssl x509 -in newcert.pem -out newcert.crt}}}

  1. {{{cp newcert.crt /etc/ssl/certs/mail.ps.uni-saarland.de.crt

cp newcert.key /etc/ssl/private/mail.ps.uni-saarland.de.key}}}

Mailing List (mailman)

Administration tools

The administration of the mailing lists (list exist mailing lists, change the mailing lists' administrators password, remove/add mailing lists is done via the tool located in /usr/lib/mailman/bin. They are named in a meaningful way.

Supported email-addresses

This is a list of all currently accepted email-addresses.

RBG Aliases

The following aliases are configured on the RBG Mailserver (mail.cs.uni-saarland.de) for @cs.uni-saarland.de: 

smolka:                 smolka@ps.uni-saarland.de
g-smolka:               g-smolka@ps.uni-saarland.de
csadminps:              cs-admin@ps.uni-saarland.de
sek-gs:                 sek-gs@ps.uni-saarland.de
tapkan:                 tapkan@ps.uni-saarland.de
duchier:                duchier@ps.uni-saarland.de
henz:                   henz@ps.uni-saarland.de
mehl:                   mehl@ps.uni-saarland.de
mmueller:               mmueller@ps.uni-saarland.de
niehren:                niehren@ps.uni-saarland.de
popow:                  popow@ps.uni-saarland.de
schulte:                schulte@ps.uni-saarland.de
vanroy:                 vanroy@ps.uni-saarland.de
walser:                 walser@ps.uni-saarland.de
wuertz:                 wuertz@ps.uni-saarland.de

The following mail addresses are dropped on the RBG mail server: 

neumann@ps.uni-saarland.de
anwalt@ps.uni-saarland.de
dansim@ps.uni-saarland.de
lorenz@ps.uni-saarland.de
2019-12-04 16:04