Re: MIME based remailing commands

[Hal <hfinney@shell.portal.com>]

-----BEGIN PGP SIGNED MESSAGE-----

lcottrell@popmail.ucsd.edu (Lance Cottrell) writes:
>With Mixmaster, everything is hidden inside the encrypted and ascii armored
>message structure.
 
>I use the :: token to let the remailer know that this is a remailer message
>of some sort. The Remailer-Type will eventually be used to indicate the
>version that created the message. It would be easy to add support for MIME.
>It would just replace the token and version number.
 
>All remailing instructions are inside the ascii armor.
>Note that the block of ascii armor is allways exactly the same length.
 
>::
>Remailer-Type: 2.0
 
>-----BEGIN REMAILER MESSAGE-----
>hQCMAgbmF1BLzawNAQP/RFw2/UagugMFPlnJ94KLmhaxDoplzAhNBCxuFRL2fosL
>V1YnFd2XVckJJ6vTe6DB+POO+V7HEdXkp3sWtjb56Am+/B+tM1TdeC6NPNV4g5PC
>[...]

Ah, I see how you are doing it.  Having re-read your docs, I gather
that when un-armored the file is in an encrypted binary format, and
when decrypted at least the non-header portion of the file is still
binary?  I think this is a good way to do it; it addresses the point
Eric made recently about size expansion when an armored file is
encrypted at each step.

The one thing I would mention is that "::" was not originally intended
as an indication that the message was to be remailed.  Rather, this was
simply a "header pasting token" which could be used to move a few lines
from the body up into the header for those people who can't set header
fields on outgoing mail.  Then the presence of "Anon-To:" or whatever
in the header is what actually causes the action.  So you don't need to
use "::", you can just set your headers directly and get the same
effect.  (This is not to say you need to do it like this, just that
that is how the original design that Eric created worked.)
 
If you did want to follow this model, you could think about using a
MIME header to indicate the type of the message contents rather than
the "::".  Another alternative would be to use a different special
field in the mail header, like perhaps your "Remailer-Type: 2.0", but
I'm not sure that a new top-level header field is the right place for
this.  It looks to me like most of the standard headers deal more with
moving the message around rather than with telling what would be done
with it on receipt.  It's kind of a fine line but it looks to me like
more of a job for a MIME content type since that is really what it is
for.  You could use something like:
 
MIME-Version: 1.0
Content-Type: application/remail; version="2.0"

or

MIME-Version: 1.0
Content-Type: application/remail-mark-2
 
Then the rest of the message could look just as you have it.  Or, to use
a little more of the existing standard, you could add:
 
Content-Transfer-Encoding: base64
 
and take out your BEGIN and END lines since it looks like you are using
base64, although the augmented kind that PGP uses with the CRC at the
end; you'd have to lose the CRC in that case.  (I wonder if PGP will do
that in the MIME-PGP integration draft that is supposedly being worked
on.)

One question is, how do you actually send your messages in the
mixmaster client and servers?  Do you go directly to sendmail, or do
you use a user agent like /bin/mail?  If the former then it doesn't
seem like it would be too hard to add these header fields.  On the
receiving end then hopefully also it would not be much harder to match
the Content-Type: string than the one you are using.

The advantage, again, is that to a considerable extent this kind of
application is exactly what MIME was planning for with the "application"
content-type.  This lets you mark the contents of the message in a
standard way.  And you are already using something very close to the
base64 encoding that MIME specifies.  So this does seem like a good
opportunity to go with the internet mainstream by following this
standard.  If this seems like something you want to do I'm sure our MIME
experts here can tell how to define a new content type.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLzpMORnMLJtOy9MBAQHWTwIA5k+6zO6/mMagKrNZELu7gHO2USlPnVGI
+SnIaj1jGtkzaodyIaEiUptAB4v5xfX8Lg7f+lcGzJYcEGrIi3+UPQ==
=NK01
-----END PGP SIGNATURE-----