Submission of SMTP messages is normally unauthenticated---the SMTP client performs no authentication of who it "really" is and merely submits a message. (See RFC 821.) SASL and specifically the AUTH SMTP extension (see RFC 2222) provides a protocol by which an SMTP client can authenticate itself to the server. SMTP server support for SASL can be controlled by various channel keywords, as described in Section 2.3.4.42 and Section 2.3.4.45. The default is that the SMTP server does not advertise nor support SASL use, nosasl.

Note that the authentication source and mechanisms supported for SASL use by the SMTP server and controlled by the PMDF security configuration file, as discussed above in Section 14.2.

One use of SASL in the SMTP server is to allow authenticated clients to perform message submissions that would be disallowed to unauthenticated clients. For instance, a site that generally blocks SMTP relaying through their SMTP server, but wants to allow such SMTP relaying for specific users who will authenticate themselves using SASL, might use channel definitions along the lines of:

tcp_local smtp mx single_sys maysaslserver saslswitchchannel tcp_auth TCP-DAEMON tcp_auth smtp mx single_sys mustsaslserver TCP-AUTH

with an ORIG_SEND_ACCESS mapping table along the lines of:

ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NSMTP$ relaying$ not$ permitted

Here the tcp_local channel is assumed to be the external TCP/IP channel. An attempt to submit without authentication a message that would go straight back out the tcp_local channel will be rejected due to the ORIG_SEND_ACCESS entry shown. But if a connection from an external system performs SASL authentication, the connection is switched to the tcp_auth channel. The tcp_auth channel will not allow messages submission unless the remote connecting client successfully authenticates itself. For connections that do authenticate, the messages will be accepted on the tcp_auth channel, and can be relayed out via the tcp_local channel, should that be the appropriate destination channel.

A similar example would be for a site that also allows relaying by "internal" clients or systems, using switchchannel and rewrite rules to associate and switch "internal" connections -- connections from .example.com subdomains or IP addresses in the 1.2.3.0 subnet--- to their tcp_internal channel. Such a site might use rewrite rules:

.example.com $U%$H$D@TCP-INTERNAL [1.2.3.] $U%[1.2.3.$L]@TCP-INTERNAL$E$R

and channel definitions along the lines of

tcp_local smtp mx single_sys maysaslserver saslswitchchannel tcp_auth \ switchchannel TCP-DAEMON tcp_internal smtp mx single_sys maysaslserver allowswitchchannel TCP-INTERNAL tcp_auth smtp mx single_sys mustsaslserver noswitchchannel TCP-AUTH

with an ORIG_SEND_ACCESS mapping table along the lines of:

ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NSMTP$ relaying$ not$ permitted

Connections from internal systems will be switched to the tcp_internal channel. That channel will permit SASL use (though clients need not bother to use SASL). Connections from external systems that use SASL to authenticate will be switched to tcp_auth. Since the tcp_internal and tcp_auth channels can send out via tcp_local (are not blocked by ORIG_SEND_ACCESS), then messages from internal users or from external users who use SASL authentication will be permitted to be submitted to the Internet. But all other attempted messages submissions from external systems, to attempted Internet destinations, will be rejected due to the ORIG_SEND_ACCESS entry.

TCP/IP channels can also be configured to place the SASL authenticated address in the headers; see Section 2.3.4.43 and Section 16.1.3.

Note that if you are using a compiled PMDF configuration, you will need to recompile and reinstall it after making changes to TCP/IP channels in the PMDF configuration file. Also, after changes to TCP/IP channel definitions, the PMDF SMTP server should be restarted with the command PMDF RESTART SMTP (OpenVMS) or pmdf restart smtp (UNIX) or pmdf restart dispatcher (NT).