Delivering email

From Syscore

Contents

HOW TO: Configuring an MX server

Apart from what's automatically installed on a server via Jumpstart and cfengine, the MX servers have some special configuration that needs to be done

Kerberos key for postman

You need to use kadmin to place the kerberos key for the 'postman/shorthostname' user in /local/mail/postman.keytab. (by that I mean, the key for postman/mx1 or the like.) If such a key doesn't already exist, create it on the KDC. That means you'll probably have to add it to the AFS pts database (pts createuser postman.mxwhatever) and add it to the postmen group (pts adduser postman.mxwhatever postmen). Note, that sendmail will not actually start if it can't get a Kerberos key, so letting a mail server come up without one won't cause armageddon. It just won't work.

File: miltersecret

Copy the file /local/mail/miltersecret from one of the other mx servers. If you don't have any other mx servers, stick some output of /dev/random into it and put it on all of your new mx servers.

File: /etc/ssl

The mail servers need the certificate and private key for 'smtp.umbc.edu'. Please copy this from one of the other mail servers.

That's it, once that's done and you do something to restart everything (like reboot) you'll have a fully functional mail server that's capable of delivering mail.

REFERENCE: Transporting and delivering email

Mail Transport Agent

Our current MTA is a locally modified version of Sendmail 8.13.5. The source tree for said is located at '/afs/umbc.edu/src/apps/sendmail/sendmail_8_13_5_umbc'. It is installed with /local/mail as it's prefix, so you'll find binaries and things like that in '/local/mai/bin', '/local/mail/sbin', etc.

To start and stop the MTA processes, run the /etc/init.d/mta script with the approrpiate start and stop arguments. The MTA processes are run from the script /local/mail/scripts/run, which executes all of the various processes with command line arguments to tune various parameters as to how they behave and process their queues. Various timeouts, sort orders, and features (like the host status directory) are used for the various queues. The following 5 processes are currenly ran:

The Delivering Agents

The "delivering agents" listen on the primary interface of the machine on port 25, 587 & 465. These agents run with delivering privileges, and submit their messages to the milter listening on the '/tmp/milter.socket'. It will not accept a mail connection if the mail filter is not available to process the message.

  • listener - This is the process that listens on the TCP ports. It's currently configured to do what's called 'interactive' delivery; meaning, it will try to deliver the message (and return Ok) while during the SMTP transaction. This is the fastest mode of sendmail operation, as sendmail will not even write a queue entry to the disk unless there is a problem.
  • local - This process runs the 'local' mailqueue, meaning stuff that was destined for local delivery. You'll also find DSNs from local delivery problems hanging out there.
  • internal - This process runs the 'internal' mailqueue, which is used for any messages not local, but destined for hosts within the *.umbc.edu domain.
  • remote - This process runs the 'remote' mailqueue, which is for mail that is destined for hosts outside of umbc.
  • slow - This process runs the 'slow' mailqueue. No mail is currently getting depositited here automatically, but gets depositied from scripts that run and move jobs out of the other queues that are just slowing things down, and we can take or leisurly time trying to deliver them.

The master sendmail configuration file for these is '/local/mail/combined.cf'.

Because of limitations on the parameters you can pass on the command line, a perl script (munge_cf) does some basic replacements on certain parameters in the cf file.

tokenizer.pl is a simple perl script that manages the AFS credentials for it's child sendmail process.

Our current sendmail build/cf tree is at: /afs/umbc.edu/src/apps/sendmail/sendmail_8_13_5_umbc

The Relay Agent

A secondary IP address is configured on the 'mx' machines, with yet another sendmail configuration running on ports 25, 465 & 587. This also known as "smtp.umbc.edu", and accepts mail from clients. It only does virus filtering, but if the filter isn't available (/tmp/relay-milter.socket), it continues to accept mail which will then immediately be passed off to the delivery agents for processing. This separate configuration exists to provide quick service to client applications even when the delivery agents are under heavy load or not accepting connections for various reasons.

Ports

As mentioned earlier, these machines listen on three ports, which have the following characteristics

  • 25 - Standard SMTP port. This accept messages and relay under the following conditions:
    • The connection is from a umbc.edu/130.85/16 host.
    • The connection was preceded by a POP/IMAP transaction that has placed the IP address of the user in the DRAC db.
    • The user's connection was authenticated via SMTP AUTH (a STARTTLS would be required before this.
  • 587 - The MSA port. This port will only relay if the user has authenticated via SMTP AUTH+STARTTLS
  • 465 - The SSL port. Same rules apply as port 25, with the exception, obviously, that a STARTTLS isn't require before AUTH
DRAC

DRAC is this silly POP/IMAP before SMTP solution that has been in place for awhile, and should be retired becuase SMTP AUTH is the way to go. However, we seem to never want to force our users to change configurations around here, so it'll probably stick around until way after Apple's first G99 laptops come out. Basically, our POP & IMAP servers send a little RPC packet to all of the mxout machines when someone logs in via IMAP & POP that contains the user's IP. A daemon (rpc.dracd) that runs on these boxes receives it, and puts that IP and an expiration timestamp in a database, which sendmail queries via some modifications to it's relay authorization stuff. See the bits of proto.m4 surrounded by USE_DRAC.

Local Delivery Agent

The LDA at UMBC is Procmail (http://www.procmail.org). Procmail is a piece of poop for a variety of reasons. However, it's been used here for years, and I don't see anyone ever supporting a change to a more reasonable alternative. Our procmail has been locally modified to handle various things, such as doing maildir style delivery, using smrsh for all exec'd processes, and security enhancments to limit file delivery outside of a users' home AFS volume.

Our current procmail build tree is at: /afs/umbc.edu/src/afsapps/MDA/procmail-3.22-umbc

Queue Management

There is an automated script, /local/mail/scripts/queue_munger, which runs every 15 minutes and moves queue entries around. Currently, it:

  • Moves anything out of the standard remote and internal queues that have been sitting there for a day to the slow queue.
  • Moves anything out of the local queue that's a DSN that's been sitting there for a day to the slow queue.

There is also a script that runs every 15 minutes which clears the queues of any spam-bounces. These are bounces generated due to messages with a spam score greater than 10. They are simply removed from the queue with qtool.pl. (it's /local/mail/scripts/spam-cleaner.pl)

Mail Filtering

Sendmail submits all incoming mail connections to a local milter through a UNIX socket. The milter is a filter-multiplexer called MilterMonkey -- the script that runs it also doubles as its configuration file. It runs two modules -- one that submits the message to scanning by ClamAV, the second submits the job to Spam Assassin. For a detailed discussion of mail filtering at UMBC, see Mail Filtering.

Anti-Virus

We run the open-source ClamAV as our email anti-virus solution. clamd listens on a local socket on the machine. freshclam runs every 15 minutes to automatically update the signatures.

Anti-Spam

SpamAssassin's spamd runs on a locally bound port.

Relay Access Control

Dynamic Blacklisting

Current hardware and configuration

  • Hardware
    • IP load balancer mxin.umbc.edu and smtp.umbc.edu
      • UMBC's mail exchanger of record (Primary MX)
    • MX cluster
      • mx1 - mx5.umbc.edu
      • Running on Sun V20z systems with Solaris 10
      • Running sendmail-8.13.5 (locally modified) and listening on port 25
      • Running with procmail 3.22 (locally modified)
  • Configuration

All of the configuration, and scripts on these machines that are mail-related are located in the directory /local/mail, which is also lofs mounted as /etc/mail for ease of use. The /usr/lib/sendmail binary and /etc/mail/sendmail.cf are standard UMBC client sendmail configs -- the binaries and configurations used for actual mail delivery and processing are separate from these.

The machines contain all of the components for mail delivery (except for the end storage!)