-----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-----