Skip to main content

Routing Email Through SMTP Relays

As of July 2010, the Stanford outgoing email server (smtp.stanford.edu) requires email clients to use a TLS (Transport Layer Security) secure email connection to encrypt email sessions. An encrypted SMTP session protects the information transmitted between the client machine and the SMTP server.

Overview

Many departments and groups on campus prefer to create and maintain their own email server. To ensure that Stanford University data is handled in a safe and secure manner, the SMTP servers require end-to-end encryption for all mail in transit. To ensure that your mail server meets these standards, please review the following recommendations. If you are unsure about the impact of implementing these recommendations or want additional guidance regarding securing university data, please contact the Information Security Office.

The following examples provide simple configurations to help you quickly set up a secure email connection:

It is strongly recommended that you read the reference material included in the instructions to fully understand how TLS works and the implication of turning it on.

Note: To ease the transition from a non-secure connection to a secure connection, the smtp.stanford.edu server does not currently require client-server certificate validation. This means that your server and the central server do not need to exchange certificates. The TLS connection is purely for transport layer encryption, not for authentication.

Note: If you have an applications or server that can't make an encrypted connection to smtp.stanford.edu you can configure it to send mail through smtp-unencrypted.stanford.edu without encryption.

Configuring Postfix

Encrypt outbound SMTP traffic from Postfix to foreign host

If you only need to send outgoing mail from your system then these steps will enable you to send through smtp.tanford.edu with an encrypted connection.

  1. Check Postfix for TLS support.

    Most likely your Postfix package that comes with your system is already built with TLS support. You can verify this by running the ldd command on client binary smtp and server smtpd. If the output of ldd contains libssl library, the Postfix supports TLS.

    The following example on a Red Hat system shows that the Postfix package is built with TLS support:
      
    mymachine> ldd /usr/libexec/postfix/smtp |grep ssl
libssl.so.4 => /lib/libssl.so.4 (0x00c54000)
    mymachine>ldd /usr/libexec/postfix/smtpd | grep ssl
libssl.so.4 => /lib/libssl.so.4 (0x008d3000)

    Note: ldd is not available on systems running Mac OS X; use otool instead (the Apple Developer Tools must be installed):

    mymachine$ /Developer/usr/bin/otool -L /usr/sbin/postfix | grep ssl
	/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)

    Recent versions OS X should have a compliant version of Postfix.

  2. Configure Postfix to route mail through smtp.stanford.edu and to use TLS when sending mail.

    In /etc/postfix/main.cf, add: 
    # route all mail through smtp.stanford.edu
relayhost = smtp.stanford.edu
    ########################################################
# TLS smtp client configuration for Postfix 2.3 client
########################################################

smtp_tls_loglevel = 1
smtp_tls_security_level = may

########################################################
# TLS smtp client configuration for Postfix 2.2 client
########################################################

smtp_tls_loglevel = 1
smtp_use_tls = yes
  3. Restart Postfix.

Encrypt inbound SMTP traffic to Postfix from foreign host

If you run an email server that accepts incoming email, you will need to install an SSL certificate on your server. In general, the central email servers try to use a TLS connection first and then fall back to a non-TLS connection if your server does not support TLS. For some campus domains or severs, the Information Security Office requires that the connection between these domains and central servers to be encrypted both ways. The central server will require TLS to these domains, and the messages to your domain will be held until a TLS connection can be established.

  1. Obtain an SSL certificate for your server.

    To support TLS for your email server, you should get a commercial SSL certificate. Or, you can install a self-signed certificate with the openssl command or other tools that can generate an SSL certificate.
  2. Iinstall your RSA key certificate and then configure TLS in Postfix's main.cf file.

    Here is an example:

    In /etc/postfix/main.cf, add (your certificate path may varies): 
    ################################################
# TLS smtpd daemon configuration
################################################
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_CAfile = /etc/ssl/certs/CAfile
smtpd_tls_cert_file = /etc/ssl/certs/smtp.pem
smtpd_tls_key_file = /etc/ssl/private/smtp.key
smtpd_tls_mandatory_exclude_ciphers = aNULL

smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may

    Note: Users of Mac OS X 10.4 must also specify smtpd_use_tls = yes.

Reference for Postfix TLS support

For more information about how Postfix TLS support works and other configurations, see www.postfix.org/TLS_README.html

Configuring Sendmail

Encrypt outbound SMTP traffic from Sendmail to foreign host

  1. Configure Sendmail to send through smtp.stanford.edu

    Edit /etc/mail/sendmail.cf and find the line that starts with DS. Change it to read:

    DSsmtp.stanford.edu

    Alternately, if you build configuration files using m4, add the line:

    define(`SMART_HOST', `smtp.stanford.edu')

    to sendmail.mc and then rebuild your sendmail.cf file. You will need to restart sendmail for this change to take effect. 
  2. Check Sendmail for TLS support.

    It is strongly recommended that you to upgrade Sendmail to the latest version to get the TLS support and to close other security holds.

    To verify if your Sendmail supports TLS, run the ldd command on the binary. For example: 
    mymachine>ldd /usr/sbin/sendmail |grep libssl
libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0x40031000)
    The output shows that the Sendmail program supports TLS.
    If Sendmail supports TLS it should attempt to use TLS by default, so connections sent to smtp.stanford.edu will be encrypted.

 

Encrypt inbound SMTP traffic to Sendmail from foreign host

If you run an email server that accepts incoming email, you will need to install an SSL certificate on your server. In general, the central email servers try to use a TLS connection first and then fall back to a non-TLS connection if your server does not support TLS. For some campus domains or severs, the Information Security Office requires that the connection between these domains and central servers to be encrypted both ways. The central server will require TLS to these domains, and the messages to your domain will be held until a TLS connection can be established.

 

  1. Get a commercial or self-signed certificate.
     

    If you run email server that accepts incoming email, you will need to install an SSL certificate on your server. In general, the central email servers try to use a TLS connection first and then fall back to a non-TLS connection if your server does not support TLS. For some campus domains or severs, the Information Security Office requires that the connection between these domains and central servers to be encrypted both ways. The central server will require TLS to these domains, and the messages to your domain will be held until a TLS connection can be established.

    To support TLS for your email server, you should get a commercial SSL certificate.

    Or, you can install a self-signed certificate with the openssl command or other tools that can generate an SSL certificate.

  2. Configuration for TLS support
    • If you use m4 (macro processor) to generate the /etc/mail/sendmail.cf file, you will need to put the following in sendmail's .mc file: 
      define(`confCACERT_PATH', `/etc/mail/certs')dnl
define(`confCACERT', `/etc/mail/certs/CAcert.pem')dnl
define(`confSERVER_CERT', `/etc/mail/certs/MYcert.pem')dnl
define(`confSERVER_KEY', `/etc/mail/certs/MYkey.pem')dnl
define(`confCLIENT_CERT', `/etc/mail/certs/MYcert.pem')dnl
define(`confCLIENT_KEY', `/etc/mail/certs/MYkey.pem')dnl
      Then re-generate the sendmail.cf file as you usually do with m4 command.
       
    • If you manage /etc/mail/sendmail.cf directly, find the section that defines CA and certificate related definitions and edit the sendmail.cf file accordingly with your certs location.

 

Reference for Sendmail TLS support 

www.sendmail.org/~ca/email/starttls.html
www.sendmail.org/m4/starttls.html

 

Adding TLS support to Java applications

  1. Ask the vendor.

    Contact the software vendors or owners to find out if the Java application is capable of supporting TLS/SSL and how to configure the application. If you write your own Java application, the JavaMail API supports SSL/TLS for all email protocols (java.sun.com/products/javamail/). Most applications have a default configuration so you just put in SMTP host name. The default configuration does not use TLS.

    The vendor application might support SSL/TLS through an alternative way for mail configuration, such as a JNDI location for email server.

    Here is an example of using SMTP over SSL: 
    <Resource name="mail/JiraSecureMailServer"
auth="Container" type="javax.mail.Session"
mail.smtps.host="smtp.stanford.edu" mail.smtps.auth="true"
mail.smtps.port="25" mail.transport.protocol="smtps"
mail.smtp.starttls.enable="true" />
  2. Run a local mail service.

    Another workaround is to run a local mail service (e.g. Postfix or sendmail), enable TLS for the local mail service and configure the Java application to use localhost instead of smtp.stanford.edu as the outgoing email server. You might want to only open port 25 to localhost if you don't plan to accept incoming email.

Adding TLS support to Exchange 2007 and above

Exchange 2007 and above support opportunistic TLS; no configuration changes are necessary to enable TLS.

If the destination SMTP server, such as smtp.stanford.edu, supports TLS (via the STARTTLS SMTP command) when sending outbound email from Exchange Server 2007 and above, the Exchange server will automatically encrypt the outbound content using TLS. In addition, inbound email sent to Exchange Server 2007 and above from the Internet will be encrypted if the sending server supports TLS (Exchange Server 2007 and above automatically install SSL certificates).

To “Require” TLS on outbound traffic, run Set–SendConnector with –RequireTLS:$True
To “Require” TLS on inbound traffic, run Set–ReceiveConnector with –RequireTLS:$True

Reference for Exchange 2010 administrators

Reference for Exchange 2007 administrators

Adding TLS support to Exchange 2003

Encrypt outbound SMTP traffic from Exchange 2003 to foreign host

This includes outbound traffic to smtp.stanford.edu, another SMTP host, or an Exchange server in a different Exchange organization.

  1. Create SMTP connector to forward mail through smart host (example: smtp.stanford.edu) for your Exchange organization. (This connector probably exists if your organization forwards all outbound mail through smtp.stanford.edu.)
  2. Add appropriate Address Space to SMTP Connector (Probably * or *.stanford.edu, depending on your routing architecture).
  3. Add appropriate 2003 servers as Local Bridgeheads on SMTP Connector.
  4. Require TLS on SMTP Connector.
    1. Obtain properties of SMTP Connector.
    2. Click the Advanced tab.
    3. Click Outbound Security.
    4. Select TLS encryption.
    5. Click OK.

Depending on routing architecture, creation of additional SMTP Connector and/or SMTP Virtual Server might be required. See msexchangeteam.com/archive/2006/10/04/429090.aspx for some related information.

Encrypt inbound SMTP traffic to Exchange 2003 from foreign host

This includes inbound traffic from smtp.stanford.edu, mx*.stanford.edu, another host, or an Exchange server in a different Exchange organization.

Note: The following steps will enable, but not require, TLS for inbound SMTP traffic.  

  1. Request and assign TLS certificate to SMTP Virtual Server on Exchange 2003 servers receiving mail from smtp.stanford.edu or mx*.stanford.edu. (It is possible to reuse SSL cert for HTTPS, if exists on server.)
    1. Obtain properties of SMTP Virtual Server.
    2. Click the Access tab
    3. Click Certificate and follow the prompts to request and assign TLS certificate.
  2. Do NOT select Require secure channel, accessible from the Communication button on the Access tab.

Encrypt 2003—2003 SMTP Traffic for servers in same Exchange organization

  1. Request and assign TLS certificate to SMTP Virtual Server on all Exchange 2003 server within Exchange organization (It is possible to reuse SSL cert for HTTPS, if exists on server.)
    1. Obtain properties of SMTP Virtual Server
    2. Go to Access tab.
    3. Click Certificate and follow prompts to request and assign TLS certificate.
  2. Do NOT select Require secure channel, which is accessible from Communication button on the Access tab.
  3. Enable Outbound Security on SMTP Virtual Server.
    1. Obtain the properties of SMTP Virtual Server.
    2. Click the Delivery tab
    3. Click Outbound Security and select TLS Encryption.

Enabling Outbound Security on SMTP Virtual Server is required for intraOrg 2003—2003 encryption. However, this configuration setting might break mailflow.

Note that an Exchange 2003 SMTP Virtual Server with TLS Outbound Security enabled cannot connect to an SMTP server that does not support TLS. Before enabling this configuration, you need to ensure that all Exchange 2003 SMTP virtual servers within an Exchange organization supports TLS, that send connectors (not SMTP virtual server) are used to send outbound internet mail, and that all send connectors are configured correctly.

Encrypt 2003—2007 SMTP traffic for servers in same Exchange organization

This configuration is tested to work, but is not officially supported by Microsoft.

  1. Enable Outbound Security on SMTP Virtual Server.
    1. Obtain properties of SMTP Virtual Server.
    2. Go to the Delivery tab.
    3. Click Outbound Security and select TLS Encryption.

Note that same concerns expressed above for enabling Outbound Security on SMTP virtual server apply.

Encrypt 2007 to 2003 SMTP traffic for servers in same Exchange organization

Due to a bug in Exchange 2003, the only method to encrypt SMTP traffic from an Exchange 2007 server to an Exchange 2003 server is via IPSec.

Reference for Exchange 2003 administrators

How to test

For an  incoming connection to your server, run the telnet command. Here is an example to test against smtp-secure1.stanford.edu:

$ telnet smtp-secure1.stanford.edu 25
Trying 171.67.22.35...
Connected to smtp-secure1.stanford.edu (171.67.22.35).
Escape character is '^]'.
220 smtp-secure1.stanford.edu ESMTP Sendmail 8.12.11/8.12.11; Sat, 1 May
2010 19:48:45 -0700
ehlo localhost
250-smtp-secure1.stanford.edu Hello luckdragon.Stanford.EDU
[171.64.11.53], pleased to meet you
250-ENHANCEDSTATUSCODES 250-PIPELINING
250-EXPN 250-VERB
250-8BITMIME 250-SIZE 50000000
250-ETRN 250-AUTH GSSAPI KERBEROS_V4
250-STARTTLS 250-DELIVERBY
250 HELP

The server's output for the ehlo command contains STARTTLS, which means the server is capable of negotiation a TLS session with a remote client.

To test an outgoing connection, you can temporarily change the smtp.stanford.edu in your email client to point to "smtp-test.stanford.edu". If your email client is configured to use TLS/SSL, your message will be accepted and delivered. Otherwise, your message will be rejected. The test server returns the error "Must issue a STARTTLS command first". You should then fix the configuration and test again. Don't forget to change back to production smtp.stanford.edu after your test.

Another way to test an outgoing connection is to send an email to smtp.stanford.edu and watch your sendmail log. You should see that the TLS session is established for your outgoing connection. You can also validate by opening up the test message and checking the raw message headers. It should look something like this:

 Received: from yourmachine (yourmachine.Stanford.EDU [some ip address])
(using TLSv1 with cipher RC4-MD5 (128/128 bits))
(No client certificate requested)
by smtp.stanford.edu (Postfix) with ESMTPSA id 7E3D6178537
for <someuser@stanford.edu>; Mon, 10 May 2010 17:12:33 -0700 (PDT)

The line with TLSv1 means the connection between your machine and the SMTP server is secure.

Last modified