Chapter 7 Connecting to Other Internet MTAs
7.3 Using TLS with SMTP
7.3.2 TLS Server
7.3.5.1 Live deployments
Normally a deployed system will use a Digital Identity and CA certificate from a proper Certification Authority. The procedure for this is outside the scope of this document. Once obtained these shosuld be installed in the filestore as described ealier in this section.
7.3.5.2
Testing and evaluation
For test purposes you may wish to use a temporary, untrusted Digital Identity. You can do this using SodiumCA.
Caution: Do not use the setup described below for a live deployment. It is for testing and evaluation only.
You first need to generate a Certificate Signing Request using SodiumCA. To do this select the MTA whose smtpsrvr is to use this Digital Identity. Using the Browse button and Create New Identity option, create a CSR and sign the CSR generated and generate the Digital Identity.
You should then put the PKCS12 file which is the Digital Identity into the directory you have configured to hold the Identity to be used by SMTP.
The use of Sodium and Sodium CA to generate a Digital Identity is discussed in the M-Switch Advanced Administration Guide, the M-Vault Administration Guide and the Strong Authentication Evaluation Guide.
After restarting M-Switch, the smtpsrvr should now report successful initialisation, as shown in Example 7.1, “Fragment of log file showing successful SMTP TLS initialisation (wrapped for ease of reading)”.
Example 7.1. Fragment of log file showing successful SMTP TLS initialisation (wrapped for ease of reading)
12/ 7 09:58:25 smtpsrvr 21078 (root ) N-IOevent-SSLID SSL/TLS loaded identity from /etc/isode/switch/tls.ok
12/ 7 09:56:33 smtpsrvr 20983 (root ) N-MTA-Notice TLS initialized
You can now test the use of TLS using openssl command line:
/opt/isode/bin/isode_openssl s_client -starttls smtp -crlf \ -showcerts -CAfile 157b9a64.0 -connect <hostname>:587
This will connect to the host, perform a starttls and the necessary handshaking required up to the point at which the SMTP command EHLO is required.
You can expect that the following will be reported:
CONNECTED(00000003)
depth=1 /C=gb/O=isode/CN=IR Test CA on attlee
verify error:num=19:self signed certificate in certificate chain verify return:0
The error indicates that the Certificate was self signed and is therefore not trusted. To configure openssl to trust the certificate you should cut and paste the PEM format server certificate reported by openssl into the ca.pem file. (With multiple trusted certificates these entries in the PEM file can be concatenated).
Example 7.2. Example ca.pem file
---BEGIN CERTIFICATE--- MIIByzCCATQCAQAwDQYJKoZIhvcNAQEEBQAwLjEOMAwGA1UEChMFSXNvZGUxDzAN BgNVBAsTBlN5c3RlbTELMAkGA1UEAxMCQ0EwHhcNMDYxMDA1MTAxMDIxWhcNMTYx MDAyMTAxMDIxWjAuMQ4wDAYDVQQKEwVJc29kZTEPMA0GA1UECxMGU3lzdGVtMQsw CQYDVQQDEwJDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsOQCD0GyjVIC ONFud88rhBWNclXshWwbfhUsMqj/214VuXa2BDROcaAQAmoT0us/T468HZ37xTVJ xaZDce36AW9zY6j141GVvEKIAoGrsDUOWLY3jL92MA8tDPsel96KVwWloe+0yoZj Vyva+I05cvzxe+uoltycg+aMOehlW9kCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBr 77U4o0yVBBueq+CmRWmphqQOp5DtWmWXbD3olCKPD9TymqLKObIyOlZpOIFfRzgK ZoNDi+hC2oQY+kuOSCRbgmL18uivxU2OsPUmfTUMZmA1g/SZBlfxYU0jN/srLMOe XK8QPruH2unAcwy1ryKbcdJgvwyjjygDtVZKnU1Z1Q== ---END CERTIFICATE---
You now need to setup the file in a format suitable for openssl:
ln -s ca.pem `openssl x509 -hash -noout < ca.pem`.0
The above line will generate a new file which can then be passed into the openssl command to configure the CA as trusted:
/opt/isode/bin/isode_openssl s_client -starttls smtp -crlf \ -showcerts -CAfile <CAfile> -connect <hostname>:587
This time you should see that the certificate has been validated successfully as trusted:
Server certificate
subject=/O=Isode/OU=System/CN=MTA issuer=/O=Isode/OU=System/CN=CA ---
Acceptable client certificate CA names /O=Isode/OU=System/CN=CA
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte
Consulting/OU=Certification Services Division/CN=Thawte Personal Freemail CA/[email protected]
7.4
Greylisting
Both the SMTP Client and Server programs contain support for the Greylisting antispam technique. This technique and relevant configuration options are discussed in detail in
Section 20.4.1, “Greylisting”.
7.5
SMTP server
The SMTP server supports the following SMTP extensions:
Description Extension
Help information [RFC 2821]
HELP
Distribution list expansion (only for X.500 Directory based lists) [RFC 2821]
EXPN
Address verification [RFC 2821]
VRFY
Message size declaration [RFC 1870]
SIZE
8bit-MIME transport [RFC 1652]
8BITMIME
Binary MIME transport [RFC 3030]
BINARYMIME
Client side pipelining [RFC 2920]
PIPELINING
Delivery Status Notifications [RFC 3461]
DSN
Enhanced Error Codes [RFC 2034]
ENHANCEDSTATUSCODES
Authentication [RFC 2554]
AUTH
Lemonade extension for message assembly during submission [RFC 4468]
BURL
Efficient sending of large MIME messages
CHUNKING
Secure SMTP over TLS [RFC 3207]
STARTTLS
Priority transfers [RFC 6710]
MT-PRIORITY
Deliver by a prescribed time [RFC 2852]
Description Extension
Future message release [RFC 4865]
FUTURERELEASE
The server program for inbound messages, smtpsrvr, makes use of additional tailoring variables in the channel specification. The per-channel variables (referred to as ‘options’) that are currently recognized are listed below.
For values which configure TLS see Section 7.3, “Using TLS with SMTP”. For values which configure SASL see Section 7.6, “SMTP authentication”.
Most of the following options are configured on the Program page of the SMTP channel. The sub-pages on the Program page are: In, Out, Errors, Anti-Spam, Auth, TLS, Greylist. This list below indicates these using [I], [O], [E], [AS], [A], [T], [G] respectively, (These are held internally (and in the mtatailor file) as channel specific or PP variables. Values which have to be configured as channel specific variables in the Advanced page are labelled [C]. Values which have to be configured as PP variables (MTA level variables) in the Advanced page are labelled [P].)
The following options control which connections/senders are accepted:
block [I]
If this option is present, it will cause the channel to block connections by always returning the 521 error code in SMTP greeting.
noname [I]
If this key has the value true, any connection is allowed. If it is not set to true, connections are only supported from hosts that can be reverse translated (the IP address, for example, can be converted back to a host name).
If this variable is present but has no value, it defaults to false. Some people consider that setting noname=false is a violation of RFC 1123 (Internet host requirements).
rbl [AS]
If this is set, it enables the Realtime Blackhole List (RBL) feature (see http:// mail-abuse.org/rbl/). A specific domain can be specified, which is used as a suffix to the calling IP address, for use with local implementation. An alternative target address can also be specified, as some RBL domains use non-standard addresses. Multiple RBL domains can be specified in a list separated using semi-colons: they are used by the SMTP inbound channel in the order in which they are specified. The syntax of the switch is:
rbl=<rbl_domain>["+"<target_address>][";"<rbl_domain>...]
Specifying just rbl is equivalent to using the normal RBL domain and default target address:
rbl=blackholes.mail-abuse.org+127.0.0.2
rblheader [AS]
If this is set, messages from remote MTAs which are found on the configured Realtime Blackhole List are not rejected, but instead have their headers annotated with
"X-RBL-FOUND: <name> (<addr>)", where <name> and <addr> are the name and
IP address of the sending system.
reject [AS]
This sets the error code used when connections are rejected (for example, for the RBL or if noname is not true and there is no domain associated with the calling IP address). It must be a three-digit SMTP status code: for example, 421 for a temporary reject, or 550 for a permanent reject.
spf [AS]
Presence of this option enables SPF [RFC 4408] lookups on the domain specified by the client in the HELO/EHLO command and on the domain part of the MAIL FROM
address. The value of this option specifies a comma separated list of conditions that should cause rejection of the SMTP connection (for HELO/EHLO check failure) or failure of an SMTP transaction (for MAIL FROM check failure). Currently recognized conditions are as follows:
• fail – ‘fail’ result from the SPF check
• soft – ‘soft Fail’ result from the SPF check, where the domain believes the host is not authorized to send email but is not willing to make that strong a statement. See section 2.5.5 of RFC 4408 for more details.
• temp – ‘TempError’ result from the SPF check, where the SPF client encountered a transient error while performing the check. See section 2.5.6 of RFC 4408 for more details.
• perm – ‘permanent error’ result from the SPF check, where the domain's published records could not be correctly interpreted. See section 2.5.7 of RFC 4408 for more details.
Unrecognized conditions are ignored. If the result of the SPF check does not match any of the specified conditions, then the X-SPF-HELO-Result (for HELO/EHLO check) and/or X-SPF-Result (for MAIL FROM check) header field is added to the message. The following options control various aspects of SMTP transactions:
maxrecips [E]
If present, sets a maximum number of recipient addresses which will be accepted for an individual message. Addresses in excess of this maximum figure will be rejected with a temporary error. The presence of large numbers of recipient addresses in a message arriving from an external MTA is often an indicator of junk mail. The default value when this option is not present is no limit.
reciplimit [E]
This option behaves similarly to maxrecips except that addresses in excess of this maximum figure will be rejected with a permanent error.
One way in which the originators of SPAM messages obtain email addresses is via Address Harvest attacks, where an SMTP client program is used to test a large range of possible recipient email addresses (for example, [email protected], [email protected], [email protected]) in the hope of finding some valid addresses. The SMTP inbound channel supports two configuration switches which can be used to reduce the vulnerability of the system to such attacks:
maxerr [E]
If present, sets a maximum number of errors which will be allowed on address-related commands (MAIL, RCPT, VRFY) before the command will no longer be accepted. When this limit has been exceeded, all further commands will be accepted, but both valid and invalid addresses will be faulted. The default value when this option is not present is ‘no limit’.
errdelay [E]
If present, sets a delay period (in seconds) which will be imposed after each
address-related error. This is designed to slow down attempts to harvest addresses (in a similar way to delays on login failure). The default value when this option is not present is ‘no delay’.
The following options control various SMTP extensions:
amms=integer [I}
This parameter specifies the maximum acceptable message size (in bytes) that the SMTP server is going to allow. It is used in the SMTP dialog with hosts supporting SMTP extensions. The default value is 0, which means ‘no limit’.
vrfy[={yes|no|auth}] [AU]
This option specifies whether the VRFY command is enabled on the server. The value of auth means that VRFY is advertised but is only allowed after successful
authentication. If the client is not authenticated, the server responds "530 5.5.1" (“Must authenticate first”). If this option is not present or is present but no value is specified, it defaults to no (the VRFY command is not supported). See also the
soft_noauth option.
expn[={yes|no|auth}] [AU]
This option specifies whether the EXPN command is enabled on the server. The value
auth means that EXPN is advertised but is only allowed after successful authentication. If the client is not authenticated the server will respond "530 5.5.1" (“Must authenticate first”). If this option is not present or is present but no value is specified, it defaults to no (the EXPN command is not supported). See also the soft_noauth
option.
absent_ret_roc [I]
This option specifies the default value of ROC (return of contents), if it is not specified in the ESMTP RET parameter to the MAIL FROM command. If this option has the value
"hdr" then only message headers are returned. If any other value is specified, or if this option is not present, the whole of the message content is returned.
original text [C]
If set to n, ROC (return of contents) is not set when gatewaying the message to an X.400 network when ESMTP RET is absent.
deliveryby=integer [I]
If set to n, then this is the minimum time (in seconds) that a message should request delivery by. If set to 0 or negative, the extension is disabled.
futurerelease=integer [I]
If set to n, then this is the minimum time (in seconds) that a message should request to be held for delivery. If set to 0 or negative, the extension is disabled.
priority_profile={profile} [I]
This indicates a priority profile that should be offered with the MT-PRIORITY extension. Current support values include MIXER, STANAG4406, NSEP and DEFAULT. The following options control handling of binary messages:
binary [I]
Allow receiving of binary messages not labeled with BODY=BINARYMIME MAIL FROM
parameter.
Note: The resulting message will probably be changed (converted) when it is relayed to another MTA. Such a message may also cause problems in processing.
line=<integer> [C]
Set the line length limit used when a BODY=BINARYMIME message is converted to 7bit. By default there is no line length limit.
7.5.1
8bit and binary data
The MIME specifications [RFC 2045] make a clear distinction between 8bit data and binary data. The former can include data with the 8th bit set (byte values 128 to 255). However, it cannot include the NUL character, nor Carriage Return or Linefeed, except as a CR LF
end of line pair. Also, 8bit data is still subject to the SMTP line length restriction of no more than 998 bytes between CR LF pairs. This makes 8bit data unsuitable for the transfer of arbitrary binary data. The SMTP server prevents the transfer in of binary data, unless the ‘binary’ option is set or BODY=BINARYMIME MAIL FROM parameter is specified (in either case the line length restriction is not applied). As a result of the way messages are handled within the Message Switch, data that violates the 8bit constraints and not labeled
with BODY=BINARYMIME may be changed and also cause problems with operation of the Message Switch.
All bodyparts of messages properly labeled with BODY=BINARYMIME are automatically converted to 7bit using base-64 or quoted-printable Content-Transfer-Encoding.
8bit data is only permitted within MIME body parts. It is not permitted to have non-ASCII characters within message or body headers. This is because there is no mechanism for assigning a character set to such characters and the same byte value corresponds to different characters in different character sets. MIME provides a mechanism for encoding non-ASCII characters within heading fields [RFC 2047]. The presence of 8bit characters in message headers can cause problems in the operation of the Message Switch.
7.6
SMTP authentication
The SMTP inbound channel supports SMTP extension for authentication [RFC 2554]. This allows connections to the SMTP server to be authenticated. RFC 2554 uses the Simple Authentication and Security Layer (SASL) framework. The SASL framework provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. See RFC 4422: Simple Authentication and Security Layer (SASL), Alexey Melnikov (Editor) and Kurt Zeilenga (Editor), June 2006 for more information. SMTP server supports various SASL authentication mechanisms as detailed below.
7.6.1
How SMTP authentication works
Authentication is configured using the Authorisation features as shown below.