1996-08-21 - Re: Securing Internet mail at the MTA level

Header Data

From: Elliot Lee <sopwith@redhat.com>
To: C Matthew Curtin <cmcurtin@research.megasoft.com>
Message Hash: bfeb0b2af18633e6b3ac7ba4a5eb280e29709ff43a168e9f53b9aec66fd475d6
Message ID: <Pine.LNX.3.95.960820170631.8463B-100000@dilbert.redhat.com>
Reply To: <199608201529.LAA01469@goffette.research.megasoft.com>
UTC Datetime: 1996-08-21 01:01:17 UTC
Raw Date: Wed, 21 Aug 1996 09:01:17 +0800

Raw message

From: Elliot Lee <sopwith@redhat.com>
Date: Wed, 21 Aug 1996 09:01:17 +0800
To: C Matthew Curtin <cmcurtin@research.megasoft.com>
Subject: Re: Securing Internet mail at the MTA level
In-Reply-To: <199608201529.LAA01469@goffette.research.megasoft.com>
Message-ID: <Pine.LNX.3.95.960820170631.8463B-100000@dilbert.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain


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."






Thread