[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TLS smpt encryption

From: Phillip Lord
Subject: Re: TLS smpt encryption
Date: Wed, 06 Sep 2006 13:07:50 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (windows-nt)

>>>>> "SJ" == Simon Josefsson <address@hidden> writes:

  >> First, the defaults. To use TLS, you have to reconfigure things
  >> like the ports manually, and have to do so in multiple places.

  SJ> The supported way to use TLS is NOT to use another port.

  SJ> The recommended practice since 1999, and probably before that,
  SJ> when RFC 2487 came out, is to use port 25 and use STARTTLS on
  SJ> that port.

I am sure that you are correct about the RFC's. Maybe, you are correct
about peoples use of ports as well, I don't know as I have a limited
number of mail servers to try out on. All I can say is that anything
which makes the task of connecting easier, including best guess
hueristics on port numbers. 

  SJ> Typically, no.

  >> So you have to change this. But this is done in
  >> smtpmail-smtp-service. The 25's in auth-credentials are only used
  >> to determine which credentials should be used.

  SJ> Right, and you could have multiple credentials, for different
  SJ> ports.

Of course, I understand that the system as you have it set up offers
more flexibility and that this is a good thing. However, the
duplication of  port numbers in general is confusing. You have said,
after all, that in general people use the same port. 

  >> Confusing. I don't know what the standards are, but most mail
  >> readers you just click "SSL/TLS encryption" and the ports get
  >> set, or guessed, automatically.

  SJ> Again, most programs use the same port.

  >> Second, the documentation. Take...
  >> ;;(setq smtpmail-starttls-credentials
  >> ;;      '(("YOUR SMTP HOST" 25 "~/.my_smtp_tls.key"
  >> ;;      "~/.my_smtp_tls.cert")))
  >> So, whats .my_smtp_tls.key then? Where does it come from? How do
  >> I get it? Can I use gnutls to generate it? I have no idea at
  >> all. Further investigation suggests that actually you can leave
  >> this blank, and it should still work.

  SJ> Did you read the Emacs SMTP Manual?  An old copy is available
  SJ> from:

  SJ> http://josefsson.org/smtpmail.html

Yes. My comments about the documentation come as a result of reading
it. I would not have commented on had I not done so. From my reading
of this what the certificates used in smtpmail-starttls-credentials
actually are is not described. Hence the confusion. 

  SJ> But it is also part of Emacs.

  SJ> If you don't have a X.509 certificate/key pair, you can leave
  SJ> those fields empty.  You can generate them using GnuTLS, but you
  SJ> need the server admin to recognize your certificate as well.
  SJ> Typically you don't need client authentication using TLS.

  SJ> The documentation for the variable seem sub-optimal here, so I
  SJ> have installed this change:

  SJ> --- smtpmail.el 15 Feb 2006 10:22:36 +0100 1.84
  SJ> +++ smtpmail.el 06 Sep 2006 11:07:47 +0200
  SJ> @@ -176,7 +176,12 @@
  SJ>  (defcustom smtpmail-starttls-credentials '(("" 25 "" ""))
  SJ>    "Specify STARTTLS keys and certificates for servers.
  SJ>  This is a list of four-element list with `servername' (a
  SJ>  string),
  SJ> -`port' (an integer), `key' (a filename) and `certificate' (a
  SJ> filename)."  +`port' (an integer), `key' (a filename) and
  SJ> `certificate' (a +filename).  +If you do not have a
  SJ> certificate/key pair, leave the `key' and +`certificate' fields
  SJ> as `nil'.  A key/certificate pair is only +needed if you want to
  SJ> use X.509 client authenticated +connections."
  SJ>    :type '(repeat (list (string :tag "Server")
  SJ>                  (integer :tag "Port") (file :tag "Key")

Thank you, this is much clear. 

  >> Third, it would be nice if the documentation made clear that
  >> "TLS" appears to be the same thing as "SSL" -- at least in the
  >> context of SMTP servers. I was under the impression for a number
  >> of months that I could not use encryption for SMTP as our local
  >> server requires SSL, which smtpmail doesn't do. Actually, it uses
  >> TLS. Some documentation saying "if you are required to use SSL,
  >> this is probably what you want".

  SJ> SSL is an earlier version of TLS, but they are compatible.  SMTP
  SJ> uses TLS, but people often incorrect call it SSL.  I modified
  SJ> the Emacs SMTP Manual to mention SSL:

  SJ> Index: smtpmail.texi
  SJ> ===================================================================
  SJ> RCS file: /sources/emacs/emacs/man/smtpmail.texi,v retrieving
  SJ> revision 1.13 retrieving revision 1.14 diff -u -p -r1.13 -r1.14
  SJ> --- smtpmail.texi 5 Feb 2006 22:41:31 -0000 1.13
  SJ> +++ smtpmail.texi 6 Sep 2006 09:10:43 -0000 1.14
  SJ> @@ -209,6 +209,8 @@ The following example illustrates what y
  SJ>  @cindex CRAM-MD5 @cindex LOGIN @cindex STARTTLS
  SJ> address@hidden TLS address@hidden SSL
  SJ>  Many environments require SMTP clients to authenticate
  SJ>  themselves before they are allowed to route mail via a server.
  SJ>  The two following variables contains the authentication
  SJ>  information needed for this.
  SJ> @@ -220,10 +222,10 @@ that order if the server support both.
  SJ>  The second variable, @code{smtpmail-starttls-credentials},
  SJ>  instructs the SMTP library to connect to the server using
  SJ>  STARTTLS.  This means the protocol exchange may be integrity
  SJ>  protected and confidential by
  SJ> -using TLS, and optionally also authentication of the client.
  SJ> This -feature uses the elisp package @file{starttls.el} (see it
  SJ> for more -information on customization), which in turn require
  SJ> that at least one -of the following external tools are
  SJ> installed: +using TLS, also known as SSL, and optionally also
  SJ> authentication of +the client.  This feature uses the elisp
  SJ> package @file{starttls.el} +(see it for more information on
  SJ> customization), which in turn require +that at least one of the
  SJ> following external tools are installed:
  SJ>  @enumerate @item

I would modify this a bit -- TLS and SSL are not the same thing as you
suggest. I would say explicitly what you have just described to me. 

This means the protocol exchange may be integrity protected and
confidential by using TLS, and optionally also authentication of the

TLS is a secure, encrypted communication method which is compatible
with SSL. In most cases where the system admins say that "SSL is
required", TLS will work. 

  >> Finally, it doesn't seem to work on windows. I spent three hours
  >> with a debugger a couple of days ago -- I figured this was the
  >> only way to see if I had the configuration right. It appears that
  >> starttls.el uses Unix specific process handling, so won't work
  >> with NTEmacs. I've been told that you can get this working with
  >> cygwin by calling out to kill.exe which works around the
  >> problem. Bit ugly! I realise that fixing this properly may take
  >> some time, but updating the documentation would be relatively
  >> quick!

  SJ> I've seen it suggested that people have had success on Windows
  SJ> using the starttls binary instead of gnutls-cli.  But I don't
  SJ> really know what works under Windows, so I don't know how to
  SJ> improve things here.

The problem is with your process handling. 

(signal-process (process-id process) 'SIGALRM)

wont work. If you are using the cygwin gnutls, then this can be faked
using "kill" directly, but NTEmacs cannot send this signal, at least
to my knowledge.

I might try starttls, but in general, its easier to have as few
extraneous binaries as possible, hence the desire to use

If TLS is compatible with SSL, would it not possible to use the SSL
binaries. As I say, the IMAP code works fine using SSL?

  >> At the moment, I have access to a non TLS based stream, but this
  >> isn't going to last for ever. I suspect that many people are in
  >> the same boat.

  SJ> Right.  Many people have migrated to SMTP over TLS already.

Yep. Once everwhere goes, I can no longer send email with emacs. I
spent 6 months on outlook this year and the experience was, er, less
than optimal, shall I say. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]