STARTTLS and the use of SSL
In the world of mail protocols, STARTTLS is the command used by email applications to initiate the switch-over from plain-text (i.e. unencrypted) communication to SSL (i.e. encrypted) communication. The SSL option is generally available separately for each of the POP, IMAP, and SMTP mail services.
To further complicate matters, these three mail services are available on specific “standard” ports, as well as on “alternate” ports (with slightly different – non-standard – behaviour). Normal behaviour is that the email application will initially connect to the server in plan-text over the appropriate standard port, and then (if configured to use SSL) issue the STARTTLS command to negotiate SSL settings with the server, after which the communications proceed encrypted.
However not all email applications behave the same; in particular Outlook (and its Mac equivalent, Entourage) behaves in a “broken” way, in that it does not support STARTTLS. If configured to use SSL, Outlook/Entourage assumes that the connection is entirely SSL – i.e. as soon as it connects to the server, it starts to negotiate SSL. This will not work on any of the standard mail ports because the server will be expecting clear text. It will only work on ports that are specifically defined to be SSL-only ports.
Some email application may require that you enter the alternate port numbers when configuring SSL; other email application supply the necessary port numbers automatically. For SMTP, the alternate (i.e. SSL-supporting) port is 465; for POP the alternate port is 995, and for IMAP the alternate port is 993. Normal (i.e. non-SSL) port numbers are: POP3, port 110; SMTP, port 25; IMAP, port 143.
At SFU, only mailgate.sfu.ca supports SSL connections on port 465, and only rm-rstar (popserver.sfu.ca, imap.sfu.ca) supports POP/IMAP connections (on any port).
Mobility and mail servers
Academic Computing Services at SFU recommends that email applications be configured to use “mailgate.sfu.ca” as the SMTP server hostname. Some older email application configurations may still be specifying “smtpserver.sfu.ca”. This hostname is being phased out because it does not support SSL connections for SMTP (i.e. for sending mail).
If you use the email application settings shown, then you will be able to retrieve and send SFU mail securely without reconfiguring your application, whether your computer is connected directly to SFU’s network, or whether it is connected using a highspeed service from home, or when using wireless at an off-campus location.
SSL and Authentication over SMTP
The SMTP protocol has provisions to allow the SMTP server to request authentication from the application. In Eudora, the “Allow Authorization” setting determines whether Eudora will send your password to the server if the server asks for it. At SFU, the mailgate.sfu.ca server will allow the email application to authenticate only if the SMTP connection is made over a secure SSL channel. If authentication is successful, then the user will be able to send mail to any recipient on the Internet. If authentication fails, or if the connection is not secure (not over SSL), only mail to SFU-local (i.e. “@sfu.ca”) recipients will be accepted. All others will be rejected with an error that states “Relaying denied. Authentication required.”
Many email applications (such as Eudora, Entourage, and Outlook) will not warn you if SSL fails. If that happens, authentication won’t be done. Mail to non “@sfu.ca” recipients will fail with the above error, but mail to “@sfu.ca” recipients will go through.
Mail protocols, applications and server
When you send and receive email, you use an email application (Eudora, Outlook and Entourage, and Apple Mail are examples) to communicate with a mail server (or servers). There are two main protocols which are involved in the communications between application and server: POP is the protocol used to receive mail, and SMTP is the protocol used to send mail. These mail services (POP, SMTP) are provided by logically separate servers, which is why you must specify different host names for each when configuring your email application. At SFU the POP server’s hostname is popserver.sfu.ca, and the SMTP server’s hostname is mailgate.sfu.ca
The POP protocol has always required authentication (in order to receive mail for a given user account, the account password must be supplied). By default this password is sent in plain-text (i.e. unencrypted) over the network between the application and the POP server, which means that the password is vulnerable to interception. By configuring the email application to use SSL for POP, the password is encrypted when it is sent.
The standard SMTP protocol, on the other hand, does not require authentication: when an email application sends a message through an SMTP server, the sender is not normally required prove his or her identity. This lack of authentication when sending mail is one of the main reasons that spam has flourished: it has been trivially easy in the past to send email under someone else’s name. Before system administrators began to crack down, spammers from anywhere in the world could configure their email application to send spam through virtually any SMTP server. These unprotected SMTP servers were called “open relays”, since they were “open” to the “relaying” of mail through them to recipients at other institutions.
Most systems now restrict access to their SMTP servers as one way of combating spam: if the SMTP server doesn’t know who you are when you try to connect to it, then you won’t be allowed to send mail out through it (see the notes above under the heading SSL and Authentication over SMTP for some details on differences between mail sent to SFU recipients and non-SFU recipients).
While on the SFU campus, the SMTP server “knows” who you are by your IP address: your SFU computer will have an IP address assigned by SFU, and so your email application can send mail through the SMTP server without any problems. However, when you are connecting to the Internet from home (through Shaw’s highspeed service, or through Telus’s ADSL service), or if you are using a public wireless network to connect your laptop to the Internet, then your computer will be using a non-SFU IP address; if you then attempt to send mail through SFU’s SMTP server you will get an error message, unless you configure your email application as described above, so that it uses authentication (an SFU Computing ID and password to prove you’re a valid SFU user) when sending mail from off-campus.