Re: MIME based remailing commands
Hal writes:
I can see that putting remailer commands into a specific part of a MIME multipart message has some advantages. Right now we are basically having the remailing commands be mail header fields.
OTOH it does have the advantage that it is easy to do, at least with th "::" pasting token idea (which perhaps would need to be documented in is own right).
IMHO, an ideal message would have the ability to handle nested objects of varying types, MIME is only a start. To construct a unique format for remail_messages is reasonable, perhaps even preferable. But of course, MIME *could* be a start, in a brown'n'serve roll sort of way. However, with a proprietary approach, what to use for delimiters, or quasi-parentheses (in the case of n layers of nesting, encrypted or unencrypted) needs extensive and careful consideration. This is the same dilemma many developers face with document-centric interfaces and their plethora of odd-bird formats. I say take the remail stuff out of the header altogether, MIME or not. ---------------------------------------------------------------- P M Dierking |
xpat@vm1.spcs.umn.edu says:
IMHO, an ideal message would have the ability to handle nested objects of varying types, MIME is only a start.
What is it precisely that you might want to encapsulate that MIME can't encapsulate? .pm
From: "Perry E. Metzger" <perry@imsi.com> xpat@vm1.spcs.umn.edu says:
IMHO, an ideal message would have the ability to handle nested objects of varying types, MIME is only a start.
What is it precisely that you might want to encapsulate that MIME can't encapsulate? Perry, you're missing the whole point, just like the exchange a few days about a remailer format standard. MIME is primarily a packaging standard. MIME does not define the innards, the payload, the contents. MIME is only a start at what the complete data format should look like. You say MIME, and you've not completely specified the data format, but rather constrained it in a way that most everybody basically agrees with, including me. Eric
Eric Hughes says:
From: "Perry E. Metzger" <perry@imsi.com>
xpat@vm1.spcs.umn.edu says:
IMHO, an ideal message would have the ability to handle nested objects of varying types, MIME is only a start.
What is it precisely that you might want to encapsulate that MIME can't encapsulate?
Perry, you're missing the whole point, just like the exchange a few days about a remailer format standard.
If I am missing the whole point, it is because people are being extremely vague about stating the point. This is engineering, not social science. One specifies things precisely, as in "I think MIME can't specify how to encapsulate a sound file", or "I think MIME doesn't have the right headers defined to specify how long a mail message is to be delayed". This fuzzy-engineering might feel good to some of you but from my perspective it does nothing to enhance the information content fo the discussion. Perry
Date: Wed, 8 Feb 1995 20:25:32 -0800 From: Eric Hughes <eric@remailer.net> You say MIME, and you've not completely specified the data format, but rather constrained it in a way that most everybody basically agrees with, including me. Could one of the MIME supporters (I guess that would be `most everybody') explain why anything more than a To: header and an encrypted block is desireable for the in-the-clear message? Specifically, why is it desireable to broadcast additional information about a message for which privacy is a primary concern? -- Rick Busdiecker <rfb@lehman.com> Please do not send electronic junk mail! Lehman Brothers Inc. 3 World Financial Center "The more laws and order are made prominent, the New York, NY 10285-1100 more thieves and robbers there will be." --Lao Tzu
Rick Busdiecker says:
Could one of the MIME supporters (I guess that would be `most everybody') explain why anything more than a To: header and an encrypted block is desireable for the in-the-clear message?
Specifically, why is it desireable to broadcast additional information about a message for which privacy is a primary concern?
No one said that it was desirable to do so, and MIME does not force you to do so. .pm
-----BEGIN PGP SIGNED MESSAGE----- Rick Busdiecker <rfb@lehman.com> writes:
Could one of the MIME supporters (I guess that would be `most everybody') explain why anything more than a To: header and an encrypted block is desireable for the in-the-clear message?
For one thing, you might want to know that you have an encrypted message on your hands and not just somebody's misfired GIF. For another, you might want to know where the encrypted block begins and where it ends. You might also want to have information about what kind of encoding has been done on the output of the encryption (base64, uuencode, leave it as pure 8-bit binary, etc.) And you might want to have information about what kind of encryption was used, what key was used, etc., in case you are supporting multiple encryption formats and keys. PGP, FYI, does include most of this information in the clear, albeit some in binary format. This information is generally needed for the receiver to successfully decode and receive the message, so it does have to be in the clear. Now, there may be some circumstances where this is not desired, and where you really do just want to hand the receiver a block of apparently random data, with no indications whatsoever what it is. Then by some out-of-band means you have to have arranged with the receiver that he will know exactly what transformation to do to get back the original data. For that I suppose you could just use text/plain (or something like application/data?), and it looks as opaque as could be desired. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLzvjARnMLJtOy9MBAQFxigIAyzjDVvkgb85h2gbEMqAjuATlNGo1V1u0 YQdlJannRuUX+p0kXepHJ7101ROKFUjPwCjGZXNFFmvWvGz7tByoMw== =aj4b -----END PGP SIGNATURE-----
Date: Wed, 08 Feb 1995 18:03:57 -0500 From: "Perry E. Metzger" <perry@imsi.com> xpat@vm1.spcs.umn.edu says: > IMHO, an ideal message would have the ability to handle nested objects > of varying types, MIME is only a start. What is it precisely that you might want to encapsulate that MIME can't encapsulate? And in what way does MIME encapsulation aid in the privacy goals of remailing? It seems far more likely to require that you expose information which you might prefer not to expose, much as the Privacy Enhanced Mail standard does. -- Rick Busdiecker <rfb@lehman.com> Please do not send electronic junk mail! Lehman Brothers Inc. 3 World Financial Center "The more laws and order are made prominent, the New York, NY 10285-1100 more thieves and robbers there will be." --Lao Tzu
Date: Wed, 08 Feb 95 16:37:06 CST From: xpat@vm1.spcs.umn.edu I say take the remail stuff out of the header altogether, MIME or not. If by this, you mean to follow more of the model used by remail@extropia.wimsey.com, then I completely agree. What travels in the clear should not *require* any header data. It could even include misleading headers. A remailer should be able to accept mail which is encrypted for it. It can then decode the encrypted part and discard the rest. The format of the decrypted message could be whatever works best for remailers which might or might not have anything at all to do with MIME. OTOH, if you are going to have information in the clear to support naive users or whatever, put the information in the header. The whole purpose of headers is for auxiliary information about the message and its delivery. The body is for the message itself. With MIME's approach of making every piece of information as big and clunky as possible, I'm mildly suprised that it hasn't done away with headers altogether :-) -- Rick Busdiecker <rfb@lehman.com> Please do not send electronic junk mail! Lehman Brothers Inc. 3 World Financial Center "The more laws and order are made prominent, the New York, NY 10285-1100 more thieves and robbers there will be." --Lao Tzu
participants (5)
-
eric＠remailer.net -
Hal -
Perry E. Metzger -
Rick Busdiecker -
xpat＠vm1.spcs.umn.edu