Previous Next Table of Contents

17. Technical notes

This section covers a number of techincal notes related to the operation of premail. This information should not be necessary for ordinary use.

17.1 Multiple recipients

One of the tricky problems with mail encryption packages such as premail is how to deal with multiple recipients. Based on experience with previous versions, this version of premail tries very hard to ``get it right.'' However, as a consequence, the exact behavior can sometimes be difficult to understand.

The hard part is when some of the recipients have encryption specified and others don't. What premail does is to split the recipients up into groups. If two recipients can receive the same actual message, they are in the same group, otherwise not. For example, recipients getting an encrypted and an unencrypted message cannot be in the same group. However, multiple recipients appearing in To: and Cc: fields that use the same encryption method will be in the same group. A single message, encrypted to multiple recipients, will be sent, which is considerably more efficient than encrypting separately for each recipient.

One subtle point is the handling of Bcc: recipients. The semantics of Bcc: specify that the mail be sent to each of the Bcc: recipients, but that none of the other recipients be able to find out their identity. However, encrypting to multiple recipients would defeat this, because it is possible to indentify all of the recipients of the encrypted message. Thus, each encrypted Bcc: recipient gets its own group.

Each recipient of an anonymous message also gets its own group, for similar reasons.

An attempt is made to make the headers in the message received by the recipient be the same as if no encryption were used. Specifically, the complete To: and Cc: header fields will be present, but the Bcc: field will be missing. One exception to this rule is anonymous messages, in which case the recipient can't see any information about the other recipients.

17.2 Error handling

The goal is to handle errors in the same way as sendmail. Thus, the exact handling depends on the setting of the -oe command line option. The default (as in sendmail) is -oep, meaning that the error message is printed to standard out, and the mail message is appended to the dead letter file (the location of which is a configuration option).

Another choice is -oem, in which case the error message and the mail message are packaged together and mailed back to the user. This is appropriate when the mailer has no way to deal with error messages returned from premail.

One additional choice, not provided by sendmail, is -oed, which prints the error message on standard out, but drops the mail message. This is a good choice if the mailer can interpret a non-zero return status code as indication of an error. This is the mode used by Netscape (and is automatically selected when premail is invoked as prezilla).

17.3 Security issues

In designing premail, usefulness and convenience were considered more important than top security. Nonetheless, it can provide good security, especially if you are aware of the security issues.

One overriding assumption was that your machine is secure, and that the serious threats were those of eavesdroppers on the network and e-mail forgers. In general, premail handles passive attacks quite well, while containing a number of vulnerabilities to active attacks.

Here are some potential security pitfalls with premail:

17.4 Useless features

Over the years, premail has accumulated a number of features of dubious value. One of them is support for MOSS, a nice encryption protocol that nevertheless failed to catch on. If you feel the urge to use it, documentation is available in the release notes for version 0.43.

One potentially cool feature is a server for decoding e-mail. This would be a useful feature if there were any mailers which used it. The protcol for the server was designed to be fast (much, much faster than invoking premail -decode separately for each message), as well as ``crypto-neutral,'' meaning that it doesn't contain any features designed just for crypto, and that it could be used for other tasks, for example converting image formats or character sets. Thus, a client designed to use this protocol would like be fully exportable from the US. If you're interested in integrating support for this protocol into a popular e-mail client, please get in touch with me.


Previous Next Table of Contents