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
may authenticate itself to the server. SMTP server support for SASL may
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 wishes 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-AUTHwith an ORIG_SEND_ACCESS mapping table along the lines of:
ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NSMTP$ relaying$ not$ permittedHere 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 may 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 .acme.com subdomains or IP addresses in the 1.2.3.0
subnet---to their tcp_internal channel. Such a site might use rewrite
rules:
.acme.com $U%$H$D@TCP-INTERNAL [1.2.3.] $U%[1.2.3.$L]@TCP-INTERNAL$E$Rand 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-AUTHwith an ORIG_SEND_ACCESS mapping table along the lines of:
ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NSMTP$ relaying$ not$ permittedConnections 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 may 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 may 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).