Mail

From UGCS
(Difference between revisions)
Jump to: navigation, search
 
Line 12: Line 12:
 
If for some reason, postfix can't deliver a message, it stays in a queue and is retried.  You can force postfix to reattempt delivery through <tt>sudo postqueue -f</tt>
 
If for some reason, postfix can't deliver a message, it stays in a queue and is retried.  You can force postfix to reattempt delivery through <tt>sudo postqueue -f</tt>
  
==Principles of mail deliver==
+
==Blocking recipient addresses==
 +
When a phish message is sent, we want to block the reply-to and sender addresses to block any potential replies.  These are blocked in hermes:/etc/postfix/recipient_access.  This file is a postfix map with the format "address REJECT" for addresses to block.  After you update it, run "postmap /etc/postfix/recipient_access" and "postfix reload" to update the changes.  Don't forget to test.
 +
 
 +
==Principles of mail delivery==
 
There are a couple of rules that you absolutely must not violate when you are running a mail server
 
There are a couple of rules that you absolutely must not violate when you are running a mail server
  

Latest revision as of 18:04, 14 May 2009

Mail is one of the most important (and most complex) systems on UGCS. Our current mailserver is Hermes, with Kabta as a backup.

Contents

Overview of incoming system

  • Incoming mail goes to mail.ugcs.caltech.edu (as defined in all our MX records). Postfix takes the message.
  • Next one of three things can happen:
    1. Postfix decides the mail is from an allowed network (ugcs), or from an authenticated user (users can authenticate through SASL, so they can use a password or GSSAPI). In this case, it will either be for a local user (see below) or delivered to its destination.
    2. Postfix decides the message is intended for local delivery. This is done by seeing if the address is in virtual_maps or local_recepients (from main.cf). Practically, it goes through and check ldap, local aliases, and the mailman aliases. If the domain of the destination is a UGCS domain (it's in $mydestination) but not in one of those lists, it gets rejected with an SMTP error)
    3. None of the above- the mail is rejected.

If the mail is for local delivery, it first has to go through filtering. We use amavis to do our filtering. Amavis is a meta-filter: its configuration files (in /etc/amavis on hermes) can put the mail through a variety of filters. We currently have a virus filter and a spam filter. To do this, postfix delivers mail to amavis's smtp server running on localhost:10024. Amavis then puts it through a virus check (if it's a virus, it is dropped) and spam filter (where X-Spam headers are added, and if it's above the spam kill score, it gets dropped) If the message passes, amavis delivers it to postfix on localhost:10025, and postfix delivers the message locally.

If for some reason, postfix can't deliver a message, it stays in a queue and is retried. You can force postfix to reattempt delivery through sudo postqueue -f

Blocking recipient addresses

When a phish message is sent, we want to block the reply-to and sender addresses to block any potential replies. These are blocked in hermes:/etc/postfix/recipient_access. This file is a postfix map with the format "address REJECT" for addresses to block. After you update it, run "postmap /etc/postfix/recipient_access" and "postfix reload" to update the changes. Don't forget to test.

Principles of mail delivery

There are a couple of rules that you absolutely must not violate when you are running a mail server

  1. Don't run an open relay. In most cases, postfix won't start if it thinks it is being run as an open relay.
  2. Don't send bounce messages outside your domain. This one is a little trickier. While you are allowed to send bounce messages to your own users, you absolutely must not send them to users on other system because you will be causing "backscatter spam" To prevent this, your mail server must be configured to reject messages with SMTP errors instead of bounce messages (so it must know immediately if it will be able to deliver the message)

Backups

If hermes goes down, we have a backup mail server. This is kabta, which sits in the Ruddock computer lab. It is listed as a secondary MX for all of our domains. This way, if a mail server can't contact hermes, it will send it to kabta. Kabta has a list of all valid email addresses (that it updates through some remctl commands) and will take the message and try to forward it to hermes. If hermes is down, it will sit in a queue until hermes is back up.

Unfortunately, spammers love to try sending stuff through backup mail servers (since usually they don't have as much filtering). Since kabta doesn't directly deliver mail, we don't have to worry about additional spam getting in this way. However, this does mean that most messages coming from kabta will be spam. Sorry.

See also

Personal tools