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 |

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

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

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

Rick Busdiecker says:
>     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?

With the security multiparts MIME standard.

Perry

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

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

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