MTA

A Message Transport Agent is the most basic use of Sendmail. In this mode sendmail simply accepts messages arriving from another MTA using the SMTP protocol, and forwards the message to yet another MTA somewhere else.

In this simple mode Sendmail is most commonly found in Firewalls accepting mail from the Internet. This is because Sendmail is both very secure and highly flexible: it's easy to add filters for Anti-virus and Anti-spam, it can accommodate quite complex routing designs to feed internal mail systems, and has built-in facilities for accepting and sending secure messages using TLS.

Security using TLS

TLS uses a customised version of SSL, the same protocol that is used to secure Web transactions. TLS is an addition to the SMTP protocol that is used to transport nearly all email around the Internet. In order to turn on TLS and Administrator needs to give Sendmail three things:

• Access to a Random Number Generator
• A Public Key Certificate
• An extra configuration table

A random number generator is built in to most Operating systems nowadays at the Kernel level, so this shouldn't present a problem; for older systems there are software packages available that will generate random numbers. But a word of warning: Sendmail uses a new Random number for every SMTP connection, and there are many mail systems on the Internet that use a separate connection for every message. So a busy MTA may need access to fresh random numbers many times a second. If your OS is providing these numbers from a kernel process this shouldn't be a problem, but if you are using a separate application to generate them they some times "run out" of fresh numbers, leading to either message rejections, delays or possible security weak-points.

Public Key Certificates are easily available, an Administrator has two choices: make one or buy one. You can generate your own Public Certificate very easily but they have one, very significant, drawback: they are Self-Signed. This means that the organisation that is certifying that you are who you say you are is YOU. This is probably OK if all you want Sendmail to do is Encrypt messages as they cross the Internet, but not if you need organisations who receive mail from you to be able to verify they are receiving mail from you and not someone pretending top be you. There are plenty of organisation who will sell you one or more Certificates. But another word of warning: Most certificates are provided to people setting up Web sites who want to provide SSL security, and Certificates suitable for Web use may not work for Email. This is because, in order to both Send and Receive messages an Email Server operates in both Server and Client mode, and needs a Certificate suitable for BOTH purposes - Certificates for Web servers are only validated for use with Servers, not Clients.

The configuration table tells Sendmail how to handle all its secure connections. These can be defined on a site by site basis so that an Administrator can adjust the level of security depending on what the other end is capable of. Essentially there are three modes of operation:

• Encryption
• Encrypt and Verify
• Encrypt, Verify and Lock

Encrypt, as the name suggests, simply assures that the message arriving is coming over a secure connection, it has no idea where that connection is from

Encrypt and Verify, means that Sendmail will not only insist that the message is coming over a Secure connection, but will also check the validity of the sender's Certificate by checking it with a local cache of "root" certificates.

Encrypt, Verify and Lock. This is the final level. Here Sendmail will check that the message is coming over an encrypted channel, that the Certificate being presented is actually owned by the organisation they are claiming to be, and finally that the Server sending the message is the one identified on the Certificate. This is the most secure form of TLS.

Opportunistic Encryption

A final word of warning. Once you have provided Sendmail with a Random number source and a Certificate (even a self-signed certificate) it will start encrypting messages by default. Whether sending or receiving a message part of the opening SMTP protocol allows Sendmail to check if TLS encryption is possible for the opening connection: if it is Sendmail will use it. This is, on the whole, a good idea as it prevents eavesdropping as a matter of course, but is has one drawback. It is quite possible for an Administrator to provide the Random number source and Certificate and then find that without any further work (specifically the configuration table) Sendmail will encrypt all messages going to the other party that he or she was concerned about. This is a mistake! There are a number of reasons why the TLS sequence might fail, an expired certificate for instance, and when this happens Sendmail will continue to accept mail in clear unencrypted format. without telling anyone what it's now doing. This compromises security. It is essential to place the correct entries into the Sendmail tables so that a TLS encrypted channel cannot be established the message is NOT transferred in clear. It may also be necessary to adjust rulesets in order to provide this behaviour in both Send and Receive directions.

 

Embedded Relay

There are a large number of Applications on the market that have a seriously impaired email handlers, some have known bugs, others don't support the full protocol, while some can't handle MX records. If an administrator is faced with trying to send mail to or from such a deficient system then an "embedded Relay" might be the answer. An embedded relay puts a copy of Sendmail on the same physical platform as the deficient application, configured specifically to present a fully functional mail gateway to the rest of the world. The only requirement is that the deficient SMTP gateway can listen on a port other than port 25.

The technique has a number of advantages:

• The Application does not screen-off the platform's email ability. (Many platforms will send messages to the administrator under fault conditions and receive mail with software updates in, these are blocked if the application takes over port 25)
• Sendmail can handle a full DNS interface, allowing use of MX records and other routing techniques.
• There are copious logs available in Sendmail that make support and fault handling very easy.
• Mail sent from the application could use TLS security. (rarely a feature of the built-in mail engine)
• The Embedded relay will accept mail on behalf of the Application even when it is temporarily busy or offline.