Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!ucsd!ames!ubvax!vsi1!altnet!edc From: edc@ALTOS.COM (Eric Christensen) Newsgroups: comp.mail.elm Subject: Re: Whatever happened to "Elm - the MAILER" ?? Summary: Let us refer to RFC822.... Keywords: RFC822 Encryption Message-ID: <560@altnet.ALTOS.COM> Date: 6 Jul 88 16:54:35 GMT References: <470@altnet.ALTOS.COM> <278@clout.Jhereg.MN.ORG> <485@altnet.ALTOS.COM> <10291@ncc.Nexus.CA> <1060@datapg.DataPg.MN.ORG> <520@a <23@n0atp.UUCP> <10305@ncc.Nexus.CA> Reply-To: edc@altnet.UUCP (Eric Christensen) Organization: Altos Computer Systems, San Jose, CA. Lines: 93 In article <10305@ncc.Nexus.CA> libPW.a[crypt.o] writes: >In article <23@n0atp.UUCP> barry@n0atp.UUCP (Barry S. Berg) writes: >> What I propose is to put a dummy local routine in. IBM calls this a >> user exit on their mainframe software. The local definiation would >> overide the external definition, not a lot of code would be generated, >> and the system would allow the use of crypt(1) or a PD crypt if desired. >> The following would be a code sample. > >Doing this just brings us back to the situation where site admin A >uses crypt version X, and site admin B uses crypt version Z. User@A >is still bitching because his encrypted mail worked *too* *good* >when it got to Recipient@B because noone at B can decipher the damn >thing! OK folks, there are some real problems with encrypted mail. I'm the first to admit that. But there are some benefits too. As I stated earlier, I'm for providing encryption hooks on a optional basis (actually, Dave told me this afternoon that the crypt stuff is all ifdefed in his 2.01 version). Go ahead and flame me, but finish reading the rest of this first! :-) Now, the question is how do we deal with the optional encryption? I think that embedding ANY routine into Elm itself is a mistake. I'm all for using standalone programs for these nasty little tasks. I think we should provide one PD crypt with the Elm sources, so everyone who uses Elm will have access to the same routine, but they have the option of using their own if so desired. RFC 822 deals with this issue, and as such I believe that we should do it in the same way. (We ARE trying to be fully RFC 822 compliant, are we not?) The option field specification from RFC 822 looks like this: optional-field = / "Message-ID" ":" msg-id / "Resent-Message-ID" ":" msg-id / "In-Reply-To" ":" *(phrase / msg-id) / "References" ":" *(phrase / msg-id) / "Keywords" ":" #phrase / "Subject" ":" *text / "Comments" ":" *text LOOK!>>>>> / "Encrypted" ":" 1#2word / extension-field ; To be defined / user-defined-field ; May be pre-empted Ok? Now here's the explination of the Encrypted field: 4.7.3. ENCRYPTED Sometimes, data encryption is used to increase the privacy of message contents. If the body of a message has been encrypted, to keep its contents private, the "Encrypted" field can be used to note the fact and to indicate the nature of the encryption. The firstparameter indicates the software used to encrypt the body, and the second, optional is intended to aid the recipient in selecting the proper decryption key. This code word may be viewed as an index to a table of keys held by the recipient. Note: Unfortunately, headers must contain envelope, as well as contents, information. Consequently, it is neces- sary that they remain unencrypted, so that mail tran- sport services may access them. Since names, addresses, and "Subject" field contents may contain sensitive information, this requirement limits total message privacy. Names of encryption software are registered with the Net- work Information Center, SRI International, Menlo Park, Cali- fornia. So we have a specification, as well as a registry for the encryption software. Is this so bad? Agreed, we're taking a little artistic licence with the 'encryption on, encyption off' feature, but I agree with Dave. That should probably stay. Now you can flame me! I would like to reach some agreement on this issue fairly soon. As it is, the 2.0 release will just have the crypt stuff ifdefed out. But I would really like to agree on what to do with future releases. If we've got to do it by vote, I'll accept that, but I hope that we don't have to resort to voting on every design issue, enhancement, or modification that someone comes up with. -- +-------------------------+--------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +--------------------------------------------------+ | 399 West Trimble Road | Note: There are no spelling errors in this | | San Jose, Ca. 95131 | message.... I just can't type! | +-------------------------+--------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them| +----------------------------------------------------------------------------+