This section covers a number of techincal notes related to the operation of premail. This information should not be necessary for ordinary use.
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.
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).
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:
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.