On Tue, 20 Aug 1996, C Matthew Curtin wrote:
Recently, I've been looking into securing email at the MTA level, and
Two types of approaches are possible: 1. Adding to the SMTP protocol itself, allowing for MTAs to identify crypto-capable peers, and then performing authentication and session encryption where possible. 2. Waiting for a cryptographic transport layer network protocol (such as what is being proposed in draft-ietf-tls-ssh-00), allowing SMTP to remain untouched, and only requiring MTAs to add support for the new network protocol.
I like the second approach better, because it allows more problems to be solved with one move, and it would be easier to add crypto
I mentioned my interest in an SSH-capable MTA to Tatu Ylonen
My questions are: 1. Which of the two approaches seems to make the most sense to you?
I think something like the first one would be a little bit better. In my mind I see something similar to the "ESMTP" message appearing on connection to the mail daemon - "SSLESMTP" if you will. Then client could issue a "ENCD SSL" command (or whatever) and it would go crypto. I already have used telnet and FTP clients that does something similar to this, and they work almost transparently....
2. Is there another approach that could work better? 3. Is there interest in adding SSH functionality to sendmail in the near future (either by the draft spec, or once the RFC has been published)?
Have you looked at SSL? It allows different algorithms to be used, etc. etc. (although the certificate & key distribution method uses x509, which may be a pain...?). The SSLeay library is a freely available implementation of SSLv2. Just MHO, --==== Elliot Lee = <sopwith@redhat.com> == Red Hat Software ====-- "Usenet is like a herd of performing elephants with diarrhea; massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it."