Electronic mail: servers

Aliases revisited

On page 484 we looked at how to set up individual aliases for use with mutt. Postfix and sendmail also have an alias facility, this time at the system level. The system installs a file called /etc/mail/aliases. It's there by default, so there's no particular reason to move it. The default /etc/mail/aliases looks like:

#Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
postmaster: root

#General redirections for pseudo accounts
bin:     root
daemon:  root
games:   root
ingres:  root
nobody:  root
system:  root
toor:    root
uucp:    root
#Well-known aliases -- these should be filled in!
#root:
#manager:
#dumper:
#operator:

root: grog

Each line contains the name of an alias, followed by the name of the user who should receive it. In this case, mail addressed to the users bin, daemon, games, ingres, nobody, system, toor and uucp will be sent to root instead. Note that the last line redefinesroot to send all mail to a specific user.

You must run the newaliases program after changing /etc/aliases to rebuild the aliases database. Don't confuse this with the newalias program, which is part of the elm MUA.

A couple of other uses of aliases are:

• You can also use an alias file for spam protection. If you want to subscribe to a mailing list, but you are concerned that spammers might get hold of the contents of the mailing list, you could subscribe as an alias and add something like:

  frednospamplease: fred
  

  If you do get spam to that name, you just remove the alias (and remember never to have any dealings with the operator of the mailing list again).
• Another use of aliases is for majordomo, the mailing list manager we'll look at on page 505.

By default, Postfix doesn't have a specific alias file. main.cf contains:

#alias_maps = dbm:/etc/aliases
#alias_maps = hash:/etc/aliases
#alias_maps = hash:/etc/aliases, nis:mail.aliases
#alias_maps = netinfo:/aliases

The texts dbm, hash and netinfo describe the kind of lookup to perform. For sendmail compatibility, we want hash. Assuming you also want to run majordomo, add the line:

alias_maps=hash:/etc/mail/aliases,hash:/usr/local/majordomo/aliases.majordomo

Rejecting spam

One of the biggest problems with email today is the phenomenon of spam, unsolicited email. Currently the law and ISPs are powerless against it. Hopefully the community will find solutions to the problem in the future, but at the moment keeping spam to manageable proportions is a battle of wits. There are a number of ways to combat it, of course:

• Reject mail from domains known to be spammers. Postfix helps here with a file called /usr/local/etc/postfix/access, which contains names of domains to reject.

  There are a couple of problems with this approach:

  • It's relatively easy to register a domain, so you may find the same spam coming from a different location.
  • It's relatively easy to spoof a domain name. Mail is regularly relayed, so you have to go by the name on the From line. But you can forge that, so you often see mail from yahoo.com or hotmail.com that has never been near those ISPs. Obviously it doesn't help to complain to the ISP.
• Of course, if the names are spoofed, you can still find out where the message really came from from the headers, as we saw on page 484. Or can we? There are two issues there: firstly, if the message has gone by another system, a relay, you can't rely on the headers further back than one hop. Anything beyond that can be forged.

  In the olden days, MTAs would accept mail for relaying from any system: they were so-called open relays. Spammers have found this very useful, and now most systems have restricted relaying to specific trusted systems. There are still a large number of open relays on the net, though.

  This is a problem that could theoretically happen to you: if your system is an open relay, you could end up delivering spam without even knowing it. By default, all current MTAs supplied with FreeBSD refuse to relay, but it's possible to (mis)configure them to be open relays. Be aware of the problems.

  But what if you get a message like this?

  Received: from femail.sdc.sfba.home.com (femail.sdc.sfba.home.com [24.0.95.82])
     by wantadilla.lemis.com (Postfix) with ESMTP id BCBFF6ACC0
     for <webmaster@lemis.com>; Tue, 19 Jun 2001 13:50:57 +0930 (CST)
  Received: from u319 ([24.21.217.142]) by femail2.sdc1.sfba.home.com
     (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
     id <20010619042005.FBWM26828.femail2.sdc1.sfba.home.com@u319>;
     Mon, 18 Jun 2001 21:20:05 -0700
  From: britneyvideo1234@yahoo.com
  To:
  Subject: stolen britney spears home video!!!
  Date: Thu, 19 Jun 2025 13:52:44 -0200
  

  This messagehas come from the domain home.com, though it's claiming to come from yahoo.com, but the IP address of the originating MTA does not resolve to a name. The format of the Received: headers is: announced-name (real-name [real-IP])

  The first header is correct: the name it claims to be (femail.sdc.sfba.home.com) matches the reverse lookup. In the second case though, u319 is not a valid fully-qualified domain name, and there is no second name: the reverse lookup failed. Some MTAs use the wordunknown in this case, and some even add a warning.

  Why should the IP of an MTA not resolve? It's ideal for spammers, of course: it makes them almost impossible to trace. In this case, it's probable that the IP range belongs to home.com, because they accepted the message for relaying, but the lack of a valid reverse lookup says nothing for their professionalism.
• A number of commercial and public service sites maintain a list of known spam sites. You can use them to decide whether to accept a mail message.
• The previous example shows another obvious point: this message has been forged to appear to come from yahoo.com. All messages that really come from Yahoo! have a header of this nature:

  Received: from web11207.mail.yahoo.com (web11207.mail.yahoo.com         [216.136.131.189])
     by mx1.FreeBSD.org (Postfix) with SMTP id 4079E43E65
     for <freebsd-arch@freebsd.org>; Mon, 7Oct 2002 10:39:14 -0700 (PDT)
     (envelope-from gathorpe79@yahoo.com)
  

  So if you can recognize messages claiming to come from yahoo.com, but without this kind of header, there's a good chance that they're spam.

So how do we use this information to combat spam? Postfix helps for the first three, but we need other tools for the last.

The rules for blocking unwanted messages are not included in /usr/local/etc/postfix/main.cf. Instead, they're in /usr/local/etc/postfix/sample-smtpd.cf. Copy those you want to the bottom of your /usr/local/etc/posfix/main.cf. Specifically, the variables of interest are smtpd_helo_restrictions (which relates to the sending MTA, which could be a relay), and smtpd_sender_restrictions, which relates to the (claimed) original sender. See sample-xmtpd.cf for details of all possible restrictions. The more interesting ones are:

• reject_unknown_client: reject the request if the client hostname is unknown, i.e. if the DNS reverse lookup fails.
• reject_maps_rbl: reject if the client is listed under $maps_rbl_domains. We'll discuss this below.
• reject_invalid_hostname: reject hostname with bad syntax.
• reject_unknown_hostname: reject hostname without DNS A or MX record.
• reject_unknown_sender_domain: reject sender domain without A or MX record. This is probably a forged domain name.
• check_sender_access maptype: mapname. Look the sender address up in the specified map and decide whether to reject it. We'lllook at this in more detail below.
• reject_non_fqdn_hostname: reject HELO hostname that is not in FQDN form.
• reject_non_fqdn_sender: reject sender address that is not in FQDN form.