Sendmail 8.13.3 Securing Mailing Solution

of the certificate, various administration information, such as a serial number of the

certificate, and any other required information, such as Netscape-specific tags. These

certificates are used to establish the identity and trustworthiness of the presenter, such

as a server or a client. These certificates are also used to authenticate the connecting

party and to take appropriate action, such as allowing a connection to proceed, and

mail relaying, or entry into a network. You can either use the commercial TLS/SSL

certificates (certs) to verify the identity of the Sendmail 8.13.3 server, or create your

own certificates for the Sendmail 8.13.3 servers.

RFC 2487 (SMTP Service Extension for Secure SMTP over TLS) describes how to use the

method for using TLS/SSL as a popular mechanism for enhancing TCP communications

with privacy and authentication. In most cases, the communication passes through one

or more routers that are not controlled or trusted by either entity. Such untrusted routers

can be a serious security threat. If SMTP agents are able to authenticate each others'

identities, the server can allow only communications from other SMTP agents it is

aware of or it can treat messages received from the known agents differently, compared

to messages received from unknown agents.

Cyrus SASL Support

The Simple Authentication and Security Layer (SASL), is a generic mechanism that

enables application protocols, such as SMTP and IMAP, to accomplish authentication.

Sendmail 8.13.3 uses Cyrus SASL, a product implementation of the SASL protocol, to

accomplish authentication.

Applications such as Sendmail use the SASL framework to accomplish the SASL protocol

exchange. The specific SASL mechanisms govern the exact protocol exchange. If a

framework contains n protocols and m different ways of authentication, SASL attempts

to make the framework simple so that you need to write only n plus m different

specifications, instead of n times m different specifications. With the Cyrus SASL library,

you need to write the authentication mechanisms only once, because they work with

all the servers that use the authentication mechanisms.

The way SASL works is governed by the mechanism that the client and server select

to use and the exact implementation of that mechanism.

A client application interacts with the SASL library (also known as the SASL glue layer)

as follows:

1. A client application makes a few calls to initialize the SASL library.

2. Each time the client application makes a new connection, it creates a new context

that is stored for the lifetime of that connection.

3. The client application requests the server for the list of supported mechanisms.

4. The client application feeds this list to the SASL library.

5. The client application starts the authentication with the mechanism selected by

the SASL library.

6. The server returns some bytes, which are provided to the SASL library.