Foundations of Python Network Programming

Chapter 13 ■ SMtp

254

■ Caution the same caution as before applies here. the fact that the first SMtp server accepts the message does not

mean that it will actually be delivered; a later server may have a more restrictive maximum size.

Besides message size, other ESMTP information is available as well. For instance, some servers may accept data
in raw 8-bit mode if they provide the 8BITMIME capability. Others may support encryption, as described in the next
section. For more on ESMTP and its capabilities, which may vary from server to server, consult RFC 1869 or your own
server’s documentation.

Using Secure Sockets Layer and Transport Layer Security

As discussed previously, e-mails sent in plain text over SMTP can be read by anyone with access to an Internet
gateway or router across which the packets happen to pass, including the wireless network at the coffee shop from
which your e-mail client might be trying to send. The best solution to this problem is to encrypt each e-mail with
a public key whose private key is possessed only by the person to whom you are sending the e-mail; there are
freely available systems like the GNU Privacy Guard for doing exactly this. But regardless of whether the messages
themselves are protected, individual SMTP conversations between particular pairs of machines can be encrypted and
authenticated using SSL/TLS, as introduced in Chapter 6. In this section, you will learn about how SSL/TLS fits in with
SMTP conversations.
Keep in mind that TLS protects only the SMTP “hops” that choose to use it—even if you carefully use TLS to send
an e-mail to a server, you have no control over whether that server uses TLS again if it has to forward your e-mail
across another hop toward its destination.
The general procedure for using TLS in SMTP is as follows:

1. Create the SMTP object, as usual.


2. Send the EHLO command. If the remote server does not support EHLO, then it will not
   support TLS.


3. Check s.has_extn() to see if starttls is present. If not, then the remote server does not
   support TLS and the message can only be sent normally, in the clear.


4. Build an SSL context object to verify the server’s identity for you.


5. Call starttls() to initiate the encrypted channel.


6. Call ehlo() a second time; this time, it’s encrypted.


7. Finally, send your message.

The first question you have to ask yourself when working with TLS is whether you should return an error if TLS is
not available. Depending on your application, you might want to raise an error for any of the following conditions:

•    There is no support for TLS on the remote side.

•    The remote side fails to establish a TLS session properly.

•    The remote server presents a certificate that cannot be validated.

Let’s step through each of these scenarios and see when they may deserve an error message.
First, it is sometimes appropriate to treat a lack of support for TLS altogether as an error. This could be the case if
you are writing an application that speaks to only a limited set of e-mail servers—perhaps e-mail servers run by your
company that you know should support TLS or e-mail servers run by an institution that you know supports TLS.