Elliot Lee wrote: | On Tue, 20 Aug 1996, C Matthew Curtin wrote: | > 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. like pgpsendmail? | > 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. | > 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. The big problem with adding SSL or ssh to mail transport is that both assume that mail goes from host A to host B, with none in between. This is useful, but its more useful (IMHO) to integrate something that doesn't use online key exchange to ensure end to end security. Take for example, Alice sends mail to Dave via Brian and Charlie. A point to point protocol, while useful against Eve and Mallet, doesn't address the fact that Brian works for the NSA. While if Alice's sendmail encrypts the message to Dave, then Brian and Charlie are reduced to traffic analysis instead of reading the mail. The case of mail being carried by an intermediary is still pretty large. In any event, I don't see an advantage other than buzzwords to using SSL/SSH over PGP, while I do see advantages to pgp. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume