REMAIL: standardized remailer syntax

[Ian Smith <iansmith@cc.gatech.edu>]

In reply to messsage <9404031518.AA06509@ah.com>
of  Sun, 3 Apr 94 08:18:37 -0700 regarding REMAIL: standardized remailer syntax
Ok, I've been following this discussion with keen interest as someone who
writes mail software and has written a "fairly clean" GUI interface to
anonymous remailers, both encrypted and non-encrypted (although the
differences to the user are not visible).
All this talk of a standard syntax is great, but let me inject some notes
from someone in the trenches doing this stuff:
1) Mail software authors would MUCH rather have the commands be in the
header lines. If you are writing your own software, modifying header
lines is easy.  I understand that some people can't modify their
headers due to their mail software, but ultimately this will be a chicken
and egg problem if the simple header lines are proposed. If you make
it easy for the mail software implementor, more software will be available
with the capability (or at least patches to existing software).
As for deleting subject lines, I think this reasonable to keep people
doing potentially dumb things, but someway must be provided to allow
people (and mailers) who understand what is going on to retain or insert
new subject (header) lines.  For example, my software presents a default
subject line of "NONE" on anoymous mail (which I think is an ok substitute
for ripping off the subject line), but if the user goes to the trouble
of actually typing in a subject line it should be preserved in the
resulting message.
2) MIME is a must. I just two days ago had my first user complaint that
his MIME mail was "damaged" by the remailer.  My user interface doesn't
show people the details of MIME and he "just expected it to work".
I've been considering hacks to use the :: to get the "Mime-Version" header back
into the mail, but I have no idea what other shenanigans are going on with
the remailer, and MIME parsers tend to be picky. An especially
important area is the use of line feeds and carriage returns. I don't
know how careful current remailers are to preserve the original message
text at the line level, but that's going to be a big deal.
Aside:
I've been trying to figure out how to get a MIME message part to be
a PGP signature in some reasonable way.  It *should* work if the PGP
sig is removed completely and the rest of the message stays intact.
You should be able to concatenate them at the end and then use PGP
to check it.  Has anyone actually gotten this to work yet?  PGP encrypted
messages are a lot easier as they are self contained and fit nicely
into the MIME paradigm. Also, does anyone out there know what the IANA
registered types are for PGP? I heard that they were already registered,
but I don't know the types.
3) I support Sameer's efforts as well as others for a standard syntax for
all the commands of a remailer, but some of sort of simple syntax(es)
are needed to allow users to "get their feet wet."  My mailer allows
you to just send anonymous mail (via hfinney, good job hal) without
understanding/using PGP (or even knowing what it is).  If you want to
use the PGPed version of the remailers, I require (obviously) that
you have my PGP interface set up. I went to a lot of trouble to
create as simple a drag-n-drop interface to PGP as I could, but some
people just don't want to learn it, so I had to "deal with it." This
also allows people an "upgrade path" as they get more confident
and interested in the use of remailers.
I would very much like to present a GUI interface to a lot of other
capabilities of remailers (such as chaining, the use of encrypted
reply-to blocks, etc), but these are hard to implement in "clean"
ways. Part of my philosophy in this is that sending anonymous mail
MUST be just as easy as sending normal mail... it should look the
same and work (basically) the same from the users point of view.  Any
new remailer syntax should consider how the mail program can
implement/use the syntax is reasonable ways w.r.t. to a user who
probably doesn't care about "the how" but just wants it to work.
After saying all this, let me make some suggestions to make life
easier for mail program authors:
1) All commands must be available without modifying the message
body. This is especially important with respect to MIME mail messages
whose body parts must be particularly formatted. I support E. Hughes
suggestion about what the header lines should be for anon-remail,
anon-post, etc. although this is not a big issue as long as there is a
standard way to acess functionality.
2) When automated programs respond to mail messages, they should be
formatted in ways to make it easy (preferably trivial) for programs
to detect the message and its contents.  Good example of this type
of thing: Sameer's double blind server. It sends various kinds of
control messages back to you.... it should be easy for a mail program
author to detect these and take automated actions. Another example:
Matt Ghio's anonymous ID allocator.
Ideally these should be MIME messages with particular parts that
indicate the results. I can assist people who would like to create
MIME formats for their control messages.
3) Schemes and syntaxes which require multiple steps (stages) of
user control should be avoided when possible (I realize this is not
always possible). If a user can hit "compose" and type a mail message
and then hit "send" to mail it, a very similar sequence should
be preserved when using remailers. From a user interface point of
view, forcing the user into some "sequenced steps" is irritating,
especially in a GUI which has a very "unsequenced" way of doing things.
hope this helps the discussion,
ian
---------------------------------------------------------------------------
"How soon is now?"
ian smith, multimedia computing group, georgia tech, iansmith@cc.gatech.edu