Configuring SMTP Channels

Depending on the type of installation, Messaging Server provides several SMTP channels at installation time (see table below). These channels implement SMTP over TCP/IP. The multithreaded TCP SMTP channel includes a multithreaded SMTP server that runs under the control of the Dispatcher. Outgoing SMTP mail is processed by the channel program tcp_smtp_client, and runs as needed under the control of the Job Controller.

You can modify the definitions of these channels or create new channels by adding or removing channel keywords as described in this section. In addition, an option file may be used to control various characteristics of TCP/IP channels. Such an option file must be stored in the MTA configuration directory (msg_svr_base/config) and named x_option, where x is the name of the channel. Refer to the Option File in Sun Java System Messaging Server 6 2005Q4 Administration Reference for details.

This section is divided into the following subsections:

• Configuring SMTP Channel Options

• SMTP Command and Protocol Support

• TCP/IP Connection and DNS Lookup Support

• SMTP Authentication, SASL, and TLS

• TCP/IP Connection and DNS Lookup Support

• TCP/IP Connection and DNS Lookup Support

• Specifying Microsoft Exchange Gateway Channels

• Transport Layer Security

Configuring SMTP Channel Options

TCP/IP channel option files control various characteristics of TCP/IP channels. Channel option files must be stored in the MTA configuration directory and named x_option, where x is the name of the channel. For example, /msg_svr_base/config/tcp_local_option

The option file consists of one or more keywords and associated values. For example you can disable mailing list expansion on your server by including the DISABLE_EXPAND keyword in the option file and setting the value to 1.

Other option file keywords allow you to:

• Set a limit on the number of recipients allowed per message (ALLOW_RECIPIENTS_PER_TRANSACTION)

• Set a limit on the number of messages allowed per connection (ALLOW_TRANSACTIONS_PER_SESSION)

• Fine tune the type of information logged to the MTA log file (LOG_CONNECTION, LOG_TRANPORTINFO)

• Specify the maximum number of simultaneous outbound connections that the client channel program allows (MAX_CLIENT_THREADS)

For information about all channel option keywords and syntax, see the Sun Java System Messaging Server 6 2005Q4 Administration Reference.

SMTP Command and Protocol Support

You can specify whether an SMTP channel supports certain SMTP commands, such as EHLO, ETRN, EXPN and VRFY. You can also specify whether the channel support DNS domain verification, which characters the channel accepts as line terminators, and so on. This section describes the following:

• Channel Protocol Selection and Line Terminators

• EHLO Command Support

• ETRN Command Support

• VRFY Command Support

• DNS Domain Verification

• Character Set Labeling and Eight-Bit Data

• Protocol Streaming

Table 12–21 summarizes the keywords described in this section.

Channel Protocol Selection and Line Terminators

Keywords: smtp, nosmtp, smtp_crlf, smtp_cr, smtp_crorlf, smtp_lf

The smtp and nosmtp keywords specify whether or not a channel supports the SMTP protocol. The smtp keyword, or one of its variations, is mandatory for all SMTP channels.

The keywords smtp_crlf, smtp_cr, smtp_crorlf, and smtp_lf can be used on SMTP channels to specify the character sequences that the MTA will accept as line terminators. The keyword smtp_crlf means that lines must be terminated with a carriage return (CR) line feed (LF) sequence. The keyword smtp_lf or smtp means that an LF without a preceding CR is accepted. Finally, smtp_cr means that a CR is accepted without a following LF. These option affect only the handling of incoming material.

Because the SMTP standard requires CRLF as the line terminator, the MTA always generates the standard CRLF sequence. The various smtp keywords merely control whether the MTA will accept additional non-standard line terminators. For example, you can specify smtp_crlf if you want the MTA to accept only strictly legal SMTP messages and reject any messages with nonstandard line terminators.

EHLO Command Support

Keywords: ehlo, noehlo, checkehlo

The SMTP protocol has been extended (RFC 1869) to allow for negotiation of additional commands. This is done by using the new EHLO command, which replaces RFC 821's HELO command. Extended SMTP servers respond to EHLO by providing a list of the extensions they support. Unextended servers return an unknown command error and the client then sends the old HELO command instead.

This fallback strategy normally works well with both extended and unextended servers. Problems can arise, however, with servers that do not implement SMTP according to RFC 821. In particular, some noncompliant servers are known to drop the connection on receipt of an unknown command.

The SMTP client implements a strategy whereby it attempts to reconnect and use HELO when any server drops the connection on receipt of an EHLO. However, this strategy might not work if the remote server not only drops the connection but also goes into a problematic state upon receipt of EHLO.

The channel keywords ehlo, noehlo, and checkehlo are provided to deal with such situations. The ehlo keyword tells the MTA to use the EHLO command on all initial connection attempts. The noehlo keyword disables all use of the EHLO command. The checkehlo keyword tests the response banner returned by the remote SMTP server for the string “ESMTP”. If this string is found EHLO is used; if not, HELO is used. The default behavior is to use EHLO on all initial connection attempts, unless the banner line contains the string “fire away”, in which case HELO is used; note that there is no keyword corresponding to this default behavior, which lies between the behaviors resulting from the ehlo and checkehlo keywords.

ETRN Command Support

Keywords: allowetrn, blocketrn, disableetrn, domainetrn, silentetrn, sendetrn, nosendetrn, novrfy

The ETRN command, defined in RFC 1985, provides an extension to the SMTP service whereby an SMTP client and server can interact to give the server an opportunity to start the processing of its queues for messages to go to a given host.

Using ETRN, an SMTP client can request that a remote SMTP server start processing the message queues destined for sending to the SMTP client. Thus, ETRN provides a way to implement “polling” of remote SMTP systems for messages incoming to one’s own system. This can be useful for systems that have only transient connections between each other, for example, sites that are set up as secondary mail exchange (MX) hosts for other sites that only have a dial-up connection to the Internet. By enabling this command, you permit remote, possibly dial-up, servers to request delivery of their mail.

The SMTP client specifies on the SMTP ETRN command line the name of the system to which to send messages (generally the SMTP client system’s own name). If the remote SMTP server supports the ETRN command, it will trigger execution of a separate process to connect back to the named system and send any messages awaiting delivery for that named system.

Responding to ETRN Commands

The allowetrn, blocketrn, domainetrn, and silentetrn keywords control the MTA response when a sending SMTP client issues the ETRN command, requesting that the MTA attempt to deliver messages in the MTA queues.

By default, the MTA will attempt to honor all ETRN commands; that is, the allowetrn keyword is enabled. You can specify that the MTA not honor ETRN commands by including the blocketrn keyword in the channel definition.

You can specify that the MTA honor all ETRN commands, but without echoing the name of the channel that the domain matched and that the MTA will be attempting to run by including the silentetrn keyword. The domainetrn keyword specifies that the MTA honor only ETRN commands that specify a domain; it also causes the MTA not to echo back the name of the channel that the domain matched and that the MTA will be attempting to run.

disableetrn disables support for the ETRN command entirely; ETRN is not advertised by the SMTP server as a supported command.

Sending ETRN Commands

The sendetrn and nosendetrn channel keywords control whether the MTA sends an ETRN command at the beginning of an SMTP connection. The default is nosendetrn, meaning that the MTA will not send an ETRN command. The sendetrn keyword tells the MTA to send an ETRN command, if the remote SMTP server says it supports ETRN. The sendetrn keyword should be followed by the name of the system requesting that its messages receive a delivery attempt.

VRFY Command Support

Keywords: domainvrfy, localvrfy, vrfyallow, vrfydefault, vrfyhide

The VRFY command enables SMTP clients to send a request to an SMTP server to verify that mail for a specific user name resides on the server. The VRFY command is defined in RFC 821.

The server sends a response indicating whether the user is local or not, whether mail will be forwarded, and so on. A response of 250 indicates that the user name is local; a response of 251 indicates that the user name is not local, but the server can forward the message. The server response includes the mailbox name.

Sending a VRFY Command

Under normal circumstances there is no reason to issue a VRFY command as part of an SMTP dialogue. The SMTP RCPT TO command should perform the same function that VRFY does and return an appropriate error. However, servers exist that can accept any address in a RCPT TO (and bounce it later), whereas these same servers perform more extensive checking as part of a VRFY command.

By default, the MTA does not send a VRFY command (the novrfy keyword is enabled).

If necessary, the MTA can be configured to issue the SMTP VRFY command by including the domainvrfy or localvrfy keyword in the channel definition. The keyword domainvrfy causes a VRFY command to be issued with a full address (user@host) as its argument. The localvrfy keyword causes the MTA to issue a VRFY command with just the local part of the address (user).

Responding to a VRFY Command

The vrfyallow, vrfydefault, and vrfyhide keywords control the SMTP server’s response when a sending SMTP client issues an SMTP VRFY command.

The vrfyallow keyword tells the MTA to issue a detailed, informative response. The vrfydefault tells the MTA to provide a detailed, informative response, unless the channel option HIDE_VERIFY=1 has been specified. The vrfyhide keyword tells the MTA to issue only a vague, ambiguous response. These keywords allow per-channel control of VRFY responses, as opposed to the HIDE_VERIFY option, which normally applies to all incoming TCP/IP channels handled through the same SMTP server.

EXPN Support

Keywords: expnallow, expndisable, expndefault

expnallow allows EXPN even if it has been disabled at the SMTP server level with the DISABLE_EXPAND SMTP channel option. expndisable disables EXPN unconditionally. expndefault allows EXPN if the SMTP server is set to allow it (default). Expansion can be disabled on a per-list basis, but if it is disabled at the server level, the per-list settings are irrelevant.

DNS Domain Verification

Keywords: mailfromdnsverify, nomailfromdnsverify

Setting mailfromdnsverify on an incoming TCP/IP channel causes the MTA to verify that an entry in the DNS exists for the domain used on the SMTP MAIL FROM command and to reject the message if no such entry exists. The default, nomailfromdnsverify, means that no such check is performed. Note that performing DNS checks on the return address domain may result in rejecting some desired valid messages (for instance, from legitimate sites that simply have not yet registered their domain name, or at times of bad information in the DNS); it is contrary to the spirit of being generous in what you accept and getting the e-mail through, expressed in RFC 1123, Requirements for Internet Hosts. However, some sites may desire to perform such checks in cases where unsolicited bulk email (UBE) is being sent with forged e-mail addresses from non-existent domains.

Because the introduction of DNS wildcard entries in the COM and ORG top-level domains has made mailfromdnsverify less useful, the mailfromdnsverify code has been modified. When the DNS returns one or more A records, these values are compared against the domain literals specified by the new MTA option BLOCKED_MAIL_FROM_IPS. If a match is found, the domain is considered to be invalid. In order to restore correct behavior the current correct setting is:

BLOCKED_MAIL_FROM_IPS=[64.94.110.11]

This option’s value defaults to an empty string.

Character Set Labeling and Eight-Bit Data

Keywords: charset7, charset8, charsetesc, sevenbit, eightbit, eightnegotiate, eightstrict

Character Set Labeling

The MIME specification provides a mechanism to label the character set used in a plain text message. Specifically, a charset= parameter can be specified as part of the Content-type: header line. Various character set names are defined in MIME, including US-ASCII (the default), ISO-8859-1, ISO-8859-2, and many more that have been subsequently defined.

Some existing systems and user agents do not provide a mechanism for generating these character set labels; as a result, some plain text messages may not be properly labeled. The charset7, charset8, and charsetesc channel keywords provide a per-channel mechanism to specify character set names to be inserted into message headers which lack character set labelling. Each keyword requires a single argument giving the character set name. The names are not checked for validity. Note, however, that character set conversion can only be done on character sets specified in the character set definition file charsets.txt found in the MTA table directory. The names defined in this file should be used if possible.

The charset7 character set name is used if the message contains only seven bit characters; the charset8 character set name will be used if eight bit data is found in the message; charsetesc will be used if a message containing only seven bit data happens to contain escape characters also. If the appropriate keyword is not specified no character set name will be inserted into Content-type: header lines.

Note that the charset8 keyword also controls the MIME encoding of 8-bit characters in message headers (where 8-bit data is unconditionally illegal). The MTA normally MIME-encodes any (illegal) 8-bit data encountered in message headers, labeling it as the UNKNOWN charset if no charset8 value has been specified.

These character set specifications never override existing labels; that is, they have no effect if a message already has a character set label or is of a type other than text. It is usually appropriate to label MTA local channels as follows:

l ... charset7 US-ASCII charset8 ISO-8859-1 ...
hostname

If there is no Content-type header in the message, it is added. This keyword also adds the MIME-version: header line if it is missing.

The charsetesc keyword tends to be particularly useful on channels that receive unlabeled messages using Japanese or Korean character sets that contain the escape character.

Eight-Bit Data

Some transports restrict the use of characters with ordinal values greater than 127 (decimal). Most notably, some SMTP servers will strip the high bit and thus garble messages that use characters in this eight-bit range.

Messaging Server provides facilities to automatically encode such messages so that troublesome eight bit characters do not appear directly in the message. This encoding can be applied to all messages enqueued to a given channel by specifying the sevenbit keyword. A channel should be marked eightbit if no such restriction exists.

The SMTP protocol disallows eightbit “unless the remote SMTP server explicitly says it supports the SMTP extension allowing eightbit.” Some transports such as extended SMTP may actually support a form of negotiation to determine if eight bit characters can be transmitted. Therefore, the use of the eightnegotiate keyword is strongly recommended to instruct the channel to encode messages when negotiation fails. This is the default for all channels; channels that do not support negotiation will simply assume that the transport is capable of handling eight bit data.

The eightstrict keyword tells Messaging Server to reject any incoming messages with headers that contain illegal eight bit data.

Protocol Streaming

Keywords: streaming

Some mail protocols support streaming operations. This means that the MTA can issue more than one operation at a time and wait for replies to each operation to arrive in batches. The streaming keyword controls the degree of protocol streaming used in the protocol associated with a channel. This keyword requires an integer parameter; how the parameter is interpreted is specific to the protocol in use.

Under normal circumstances, the extent of streaming support available is negotiated using the SMTP pipelining extension. As such this keyword should never be used under normal circumstances.

The streaming values available range from 0 to 3. A value of 0 specifies no streaming, a value of 1 causes groups of RCPT TO commands to stream, a value of 2 causes MAIL FROM/RCPT TO to stream, and a value of 3 causes HELO/MAIL FROM/RCPT TO or RSET/MAIL FROM/RCPT TO streaming to be used. The default value is 0.

TCP/IP Connection and DNS Lookup Support

You can specify information about how the server handles TCP/IP connections and address lookups. This section describes the following:

• TCP/IP Port Number and Interface Address

• Caching for Channel Connection Information

• Reverse DNS Lookups

• IDENT Lookups

• TCP/IP MX Record Support

• Nameserver Lookups

• Last Resort Host

• Alternate Channels for Incoming Mail (Switch Channels)

• Target Host Choice

Table 12–22 lists the TCP/IP connection and DNS lookup keywords described in this section.

TCP/IP Port Number and Interface Address

Keywords: port, interfaceaddress

The SMTP over TCP/IP channels normally connect to port 25 when sending messages. The port keyword can be used to instruct an SMTP over TCP/IP channel to connect to a nonstandard port. Note that this keyword complements the Dispatcher option PORT, which controls which ports the MTA listens on for accepting SMTP connections.

The interfaceaddress keyword controls the address to which a TCP/IP channel binds as the source address for outbound connections; that is, on a system with multiple interface addresses this keyword controls which address will be used as the source IP address when the MTA sends outgoing SMTP messages. Note that this keyword complements the Dispatcher option INTERFACE_ADDRESS, which controls which interface address a TCP/IP channel listens on for accepting incoming connections and messages.

Caching for Channel Connection Information

Keywords: cacheeverything, nocache, cachefailures, cachesuccesses

Channels using the SMTP protocol maintain a cache containing a history of prior connection attempts. This cache is used to avoid reconnecting multiple times to inaccessible hosts, which can waste lots of time and delay other messages. The cache is a per process cache and only persists during a single run of the outbound SMTP delivery channel.

The cache normally records both connection successes and failures. (Successful connection attempts are recorded in order to offset subsequent failures—a host that succeeded before but fails now doesn't warrant as long of a delay before making another connection attempt as does one that has never been tried or one that has failed previously.)

However, the caching strategy used by the MTA is not necessarily appropriate for all situations. Therefore channel keywords are provided to adjust the MTA cache.

The cacheeverything keyword enables all forms of caching and is the default. The nocache keyword disables all caching.

The cachefailures keyword enables caching of connection failures but not successes—this forces a somewhat more restricted retry than cacheeverything does. Finally, cachesuccesses caches only successes. This last keyword is effectively equivalent to nocache for SMTP channels.

Reverse DNS Lookups

Keywords: forwardchecknone, forwardchecktag, forwardcheckdelete

The forwardchecknone, forwardchecktag, and forwardcheckdelete channel keywords can modify the effects of doing reverse DNS lookups. These keywords can control whether the MTA does a forward lookup of an IP name found using a DNS reverse lookup, and if such forward lookups are requested, specify what the MTA does if the forward lookup of the IP name does not match the original IP number of the connection.

The forwardchecknone keyword is the default, and means that no forward lookup is done. The forwardchecktag keyword tells the MTA to do a forward lookup after each reverse lookup and to tag the IP name with an asterisk (*), if the number found using the forward lookup does not match that of the original connection. The forwardcheckdelete keyword tells the MTA to do a forward lookup after each reverse lookup and to ignore (delete) the reverse lookup returned name if the forward lookup of that name does not match the original connection IP address; in this case, the MTA uses the original IP address instead.

Having the forward lookup not match the original IP address is normal at many sites, where a more “generic” IP name is used for several different IP addresses.

IDENT Lookups

Keywords: identnone, identnonelimited, identtnonnumeric, identnonesymbolic, identtcp, identtcpnumeric, identtcpsymbolic, identtcplimited

The IDENT keywords control how the MTA handles connections and lookups using the IDENT protocol. The IDENT protocol is described in RFC 1413.

The identtcp, identtcpsymbolic, and identtcpnumeric keywords tell the MTA to perform a connection and lookup using the IDENT protocol. The information obtained from the IDENT protocol (usually the identity of the user making the SMTP connection) is inserted into the Received: header of the message as follows:

• identtcp inserts the host name corresponding to the incoming IP number, as reported from a DNS reverse lookup and the IP number itself.

• identtcpsymbolic inserts the host name corresponding to the incoming IP number, as reported from a DNS reverse lookup; the IP number itself is not included in the Received: header.

• identtcpnumeric inserts the actual incoming IP number—no DNS reverse lookup on the IP number is performed.

The remote system must be running an IDENT server for the IDENT lookup caused by identtcp, identtcpsymbolic, or identtcpnumeric to be useful.

Be aware that IDENT query attempts may incur a performance hit. Increasingly routers will “black hole” attempted connections to ports that they don’t recognize. If this happens on an IDENT query, then the MTA does not hear back until the connection times out (a TCP/IP stack controlled time-out, typically on the order of a minute or two).

Another performance factor occurs when comparing identtcp, indenttcplimited, or identtcpsymbolic to identtcpnumeric. The DNS reverse lookup called for with identtcp, identtcplimited, or identtcpsymbolic incurs some additional overhead to obtain the more user-friendly host name.

The identnone keyword disables IDENT lookup, but does specify IP to host name translation, and both IP number and host name will be included in the Received: header for the message.

The identnonesymbolic keyword disables IDENT lookup, but does do IP to host name translation; only the host name will be included in the Received: header for the message.

The identnonenumeric keyword disables this IDENT lookup and inhibits the usual DNS reverse lookup translation of IP number to host name, and might result in a performance improvement at the cost of less user-friendly information in the Received: header. This is the default.

The identtcplimited and identnonelimited keywords have the same effect as identtcp and identnone, respectively, as far as IDENT lookups, reverse DNS lookups, and information displayed in Received: header. Where they differ is that with identtcplimited or identnonelimited the IP literal address is always used as the basis for any channel switching due to use of the switchchannel keyword, regardless of whether the DNS reverse lookup succeeds in determining a host name.

TCP/IP MX Record Support

Keywords: mx, nomx, defaultmx, randommx, nonrandommx

Some TCP/IP networks support the use of MX (mail forwarding) records and some do not. Some TCP/IP channel programs can be configured not to use MX records if they are not provided by the network that the MTA system is connected to. The mx, nomx, defaultmx, randommx, nonrandommx keywords control MX record support.

The keyword randommx specifies that MX lookups should be done and MX record values of equal precedence should be processed in random order. The keyword nonrandommx specifies that MX lookups should be done and MX values of equal precedence should be processed in the same order in which they were received.

The mx keyword is currently equivalent to nonrandommx; it might change to be equivalent to randommx in a future release. The nomx keyword disables MX lookups. The defaultmx keyword specifies that mx should be used if the network says that MX records are supported. The keyword defaultmx is the default on channels that support MX lookups in any form.

Nameserver Lookups

Keywords: nameservers, defaultnameservers

When name server lookups are being performed, the nameservers channel keyword may be used to specify a list of name servers to consult rather than consulting the TCP/IP stack's own choice of name servers. The nameservers keyword requires a space separated list of IP addresses for the name servers, as shown in the following example:

nameservers 1.2.3.1 1.2.3.2

The default, defaultnameservers, means use the TCP/IP stack's own choice of name servers.

To prevent name server lookups on UNIX, you can modify the nsswitch.conf file. On NT, modify the TCP/IP configuration.

Last Resort Host

Keywords: lastresort

The lastresort keyword is used to specify a host to connect to even when all other connection attempts fail. In effect this acts as an MX record of last resort. This is only useful on SMTP channels.

The keyword requires a single parameter specifying the name of the “system of last resort.” For example:

tcp_local single_sys smtp mx lastresort mailhub.siroe.com
TCP-DAEMON

Alternate Channels for Incoming Mail (Switch Channels)

Keywords: switchchannel, allowswitchchannel, noswitchchannel. See also saslswitchchannel on SMTP Authentication, SASL, and TLS, and tlsswitchchannel on Transport Layer Security

The following keywords control selection of an alternate channel for incoming mail: switchchannel, allowswitchchannel, noswitchchannel.

When the MTA accepts an incoming connection from a remote system, it must choose a channel with which to associate the connection. Normally this decision is based on the transfer used; for example, an incoming SMTP over TCP/IP connection is automatically associated with the tcp_local channel.

This convention breaks down, however, when multiple outgoing channels with different characteristics are used to handle different systems over the same transfer. When this happens, incoming connections are not associated with the same channel as outgoing connections, and the result is that the corresponding channel characteristics are not associated with the remote system.

The switchchannel keyword provides a way to eliminate this difficulty. If switchchannel is specified on the initial channel the server uses, the IP address of the connecting (originating) host will be matched against the channel table and if it matches the source channel will change accordingly. If no IP address match is found or if a match is found that matches the original default incoming channel, the MTA may optionally try matching using the host name found by doing a DNS reverse lookup. The source channel may change to any channel marked switchchannel or allowswitchchannel (the default). The noswitchchannel keyword specifies that no channel switching should be done to or from the channel.

Specification of switchchannel on anything other than a channel that a server associates with by default has no effect. At present, switchchannel only affects SMTP channels, but there are actually no other channels where switchchannel would be reasonable.

Target Host Choice

Keywords: daemon, single, single_sys

The interpretation and usage of the daemon keyword depends upon the type of channel to which it is applied.

The daemon keyword is used on SMTP channels to control the choice of a target host.

Normally, channels connect to whatever host is listed in the envelope address of the message being processed. The daemon keyword is used to tell the channel to instead connect to a specific remote system, generally a firewall or mail hub system, regardless of the envelope address. The actual remote system name should appear directly after the daemon keyword, as shown in the following example:

tcp_firewall smtp mx daemon firewall.acme.com
TCP-DAEMON

If the argument after the daemon keyword is not a fully qualified domain name, the argument will be ignored and the channel will connect to the channel's official host. The official host is the fully qualified hostname associated with the channel. This can be specified in the second line of a three line channel block:

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

The official host can also be specified after TCP-DAEMON in a two-line channel block so outbound connections will identify themselves as a particular host:

tcp_firewall smtp mx daemon router
TCP-DAEMON firewall.acme.com

When specifying the firewall or gateway system name as the official host name, the argument given to the daemon keyword is typically specified as router, as shown in the following example:

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

Other keywords of interest are single and single_sys. The single keyword specifies that a separate copy of the message should be created for each destination address on the channel. The single_sys keyword creates a single copy of the message for each destination system used. Note that at least one copy of each message is created for each channel the message is queued to, regardless of the keywords used.

SMTP Authentication, SASL, and TLS

Keywords: maysaslserver, mustsaslserver, nosasl, nosaslserver, saslswitchchannel, nosaslswitchchannel)

You can control whether the Messaging Server supports authentication to the SMTP server using SASL (Simple Authentication and Security Layer). SASL is defined in RFC 2222 and or more information about SASL, SMTP authentication, and security is in Chapter 19, Configuring Security and Access Control.

The maysaslserver, mustsaslserver, nosasl, nosaslserver, switchchannel, and saslswitchchannel channel keywords are used to configure SASL (SMTP AUTH) use during the SMTP protocol by SMTP channels such as TCP/IP channels.

nosasl is the default and means that SASL authentication is not permitted or attempted. It subsumes nosaslserver, which means that SASL authentication is not permitted. Specifying maysaslserver causes the SMTP server to permit clients to attempt to use SASL authentication. Specifying mustsaslserver causes the SMTP server to insist that clients use SASL authentication; the SMTP server does not accept messages unless the remote client successfully authenticates.

Use saslswitchchannel to cause incoming connections to be switched to a specified channel upon a client’s successful use of SASL. It takes a required value, specifying the channel to which to switch.

Using Authenticated Addresses from SMTP AUTH in Header

Keywords: authrewrite

The authrewrite channel keyword and associated AUTH_REWRITE mapping table allows modification of header and envelope addresses using addressing information obtained from authentication operations. Specifically, SASL authentication can be configured to provide an authorized email address. Normally the SMTP AUTH information is used, though this may be overridden via the FROM_ACCESS mapping. The authrewrite keyword takes a required bit value, according to Table 12–23.

The $Z flag should be highly restricted as there are few legitimate uses for modifying envelope and header addresses.

Specifying Microsoft Exchange Gateway Channels

Keywords: msexchange, nomsexchange

The msexchange channel keyword may be used on TCP/IP channels to tell the MTA that this is a channel that communicates with Microsoft Exchange gateways and clients. When placed on an incoming TCP/IP channel which has SASL enabled (via a maysaslserver or mustsaslserver keyword), it causes the MTA’s SMTP server to advertise AUTH using an “incorrect” format (based upon the original ESMTP AUTH specification, which was actually incompatible with correct ESMTP usage, rather than the newer, corrected AUTH specification). Some Microsoft Exchange clients, for instance, does not recognize the correct AUTH format and only recognizes the incorrect AUTH format.

The msexchange channel keyword also causes advertisement (and recognition) of broken TLS commands.

nomsexchange is the default.

Transport Layer Security

Keywords: maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, tlsswitchchannel

The maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, and tlsswitchchannel channel keywords are used to configure TLS use during the SMTP protocol by SMTP based channels such as TCP/IP channels.

The default is notls, and means that TLS will not be permitted or attempted. It subsumes the notlsclient keyword, which means that TLS use will not be attempted by the MTA SMTP client on outgoing connections (the STARTTLS command will not be issued during outgoing connections) and the notlsserver keyword, which means that TLS use will not be permitted by the MTA SMTP server on incoming connections (the STARTTLS extension will not be advertised by the SMTP server nor the command itself accepted).

Specifying maytls causes the MTA to offer TLS to incoming connections and to attempt TLS upon outgoing connections. It subsumes maytlsclient, which means that the MTA SMTP client will attempt TLS use when sending outgoing messages, if sending to an SMTP server that supports TLS, and maytlsserver, which means that the MTA SMTP server will advertise support for the STARTTLS extension and will allow TLS use when receiving messages.

Note that for TLS to work, the following conditions must be in place:

• Protections/ownerships of the certificates have to be set so that the mailsrv account can access the files.

• The directory where the certificates are stored need to have protections/ownerships set such that the mailsrv account can access the files within that directory.

Specifying musttls will cause the MTA to insist upon TLS in both outgoing and incoming connections; email will not be exchanged with remote systems that fail to successfully negotiate TLS use. It subsumes musttlsclient, which means that the MTA SMTP client will insist on TLS use when sending outgoing messages and will not send to SMTP servers that do not successfully negotiate TLS use (the MTA will issue the STARTTLS command and that command must succeed). It also subsumes musttlsserver, which means that the MTA SMTP server will advertise support for the STARTTLS extension and will insist upon TLS use when receiving incoming messages and will not accept messages from clients that do not successfully negotiate TLS use.

The tlsswitchchannel keyword is used to cause incoming connections to be switched to a specified channel upon a client's successful TLS negotiation. It takes a required value, specifying the channel to which to switch.