Email Delivery

In the pre-commercial Internet, systems lacked direct connections. Emails for system D would be sent from system A to system B, and then to system C before being delivered to system D. The act of accepting an email on behalf of another is called relaying. The machines were acting as relays. Administrators configured their machines to relay as a matter of courtesy to others. By taking part in this relaying mechanism, the entire community shared the load.

The exploitation of relays by spammers led to administrators tightening up security and refusing to accept email from an unknown source, unless it was being sent to a local user. The machines still had to accept email for local users that was addressed to and from other domains.

A server should accept all email from its local users. Apart from that, it should only accept email for users or domains that it can deliver to. Accepting emails for other domains makes the server an open relay.

The MTA should be configured to:

• Accept mail for the list of domains it serves, and reject email for other domains.
• Identify local users and allow them to send emails to other domains.
• Validate incoming email and reject emails to invalid recipients.

The list of domains that an MTA relays email for is held in a configuration file and can be changed by the systems administrator. Local users can be authenticated by the network interface that their request appears on or by the IP address of their machine. Validation credentials of these users are also held in a configuration file. MTAs can use a variety of methods, including Lightweight Directory Access Protocol (LDAP) and Pluggable Authentication Modules (PAMs), to authenticate email recipients.