Mail Services

We provide each of our members with personal emails, as well as the right to create mailing lists through mailman. Our organizational mailing lists (announce, acm, officers, and admins) are all run through mailman as well.

Mail Security

Mail security is important. It’s embarassing for the ACM when we send out spam to our announcement mailing list. It’s annoying for users when they can’t send mail from their ACM accounts because we’ve been blacklisted. It’s really bad if emails sent to officers@, contest@, or admins@ don’t get delivered to people since we’ve been blacklisted. (I think that at least somebody should get these, since I don’t think Hopkins would blacklist us since that should be routed internally, but if our mail server is blacklisted, that’s still bad.)

THE MOST IMPORTANT THING HERE IS: if the mail server is sending spam, SHUT IT DOWN IMMEDIATELY. ssh to localadmin@crimea.acm.jhu.edu and run sudo systemctl stop postfix

The longer we’re sending spam the longer we’ll be blacklisted. More importantly, the more spam we send, the more spam we send to ACM members. Sending spam to ACM members is bad.

A Brief Intro to Mail Security Stuff

An email (loosely) consists of headers and a body. Headers are metadata like the subject, the recipient, and the sender. The body is the content of the email (loosely). If you wanted to impersonate someone in email, without defenses, you could simply send an email with the From header set to be someone else. This is problematic for us, since services that we run, like Mailman (see above) depend on the From header to figure out whether an email should actually be sent to all the users on the list.

In order to solve the problem of impersonation, one solution is called DKIM. DKIM works by putting a public key in a TXT DNS record (for us it’s mail._domainkey). We cryptographically sign every email that we send using this public key. If someone wants to figure out if we actually sent an email that they got, they can look up our DKIM key, and figure out whether it was signed by us.

That sounds all well and good in practice, but there are a couple problems. First, not all domains have DKIM keys. Second, what should we do if we encounter an email that either isn’t signed, or is improperly signed, but the domain that the email is claiming to originate from has a DKIM key (that is, suppose we get an email claiming to be from michael.jackson@gmail.com, and it’s not signed, yet gmail has DKIM keys). The solution to this is yet another DNS entry. This entry is called DMARC, and it’s used to set a policy of what to do when you receive an email claiming to be from that domain, but that’s not signed by it.

This sounds great, right? All people need to do is set up DKIM keys, and then set a DMARC policy to reject emails that aren’t signed. The problem is that many domains that we care about do not have DMARC policies that say that unsigned emails should be rejected. Gmail, for example, has a DMARC policy that says that you should allow unsigned emails claiming to be from gmail.

Layers of Defense

  • ACM Spamfilter is a piece of software that does two things. First, it runs an email through spamassassin. Next, it acts as a way to override a domain’s DMARC policy. That is, some domains (like gmail) don’t say to drop emails that aren’t signed properly. It will not touch emails to addresses like officers@, to ensure that misconfiguration (on the part of any senders) won’t prevent vital communications from reaching us. It is installed in the /opt/acm_spamfilter/ on crimea. To update it, pull from git (though you may want to stop postfix, first). Postfix is configured to use it via an entry in /etc/postfix/master.cf.
  • OpenDKIM signs all outgoing email with our public key to prove that it was sent by us.
  • OpenDMARC is a piece of software which will enforce the DMARC policies of domains on incoming emails.

Member Email

Out of a sense of tradition, our mail host is named centaur.vm.acm.jhu.edu and listens on the address mapped to centaur.acm.jhu.edu externally. See Ingress.

Postfix

We run Postfix as our MTA.

Blocking Domains

The file /etc/postfix/access contains a list of domains to be rejected. At the time of this writing, the only such domain is mms.att.net, from which we recieved a bunch of spam about six hours before the file’s creation. In postman’s main.cf primary config file, you will find the line:

smtpd_sender_restrictions = hash:/etc/postfix/access

This tells postman that in the above-mentioned file it can find a list of domains from which it should not accept mail. To add to the list of domains, you can just edit the file; add the domain and the word REJECT, as in the att.net line, then run:

postmap hash:/etc/postfix/access
systemctl restart postfix

Mail Volumes

Patching for AFS

This is exciting:

apt-get source postfix
cd postfix-${...}
patch -p1 < /afs/acm.jhu.edu/group/admins.pub/postfix-local-afs.diff
dpkg-buildpkg
  # this will take a while!
cd ..
dpkg --install postfix-${...}

You may wish to look at file:///afs/acm.jhu.edu/group/admins.pub/postfix-local-afs.diff before executing these instructions to see what’s going on in a bit more detail!

DNS Glue

Mailman and the Lists

We’re currently running mailman 2.1.18, which has been out of date for only a bit less than two years as of this writing. Mailman (or at least mailman2) is horrifically insecure and somewhat difficult to use. We should probably move to a superior list server, but we would like to port over our archives and current lists, which could take some doing.