[Nym3-devel] Specs clarification for the RELAY command.

[Laurent Fousse]

Hello,

* Nick Mathewson [2006-03-21]:
> On Sat, Mar 18, 2006 at 10:56:22PM +0100, Laurent Fousse wrote:
>  [...]
> > The nice thing with MIME reconstruction on the server is that we don't
> > even need to specify how it should be done.
> > 
> > I have two different suggestions for boundary selection :
> > 
> >     a) each boundary is cryptographically random in the set of strings
> >        of length 42 bytes consisting only of ALPHA and DIGIT (in the
> >        unlikely event of a boundary appearing in the parts, retry).
> 
> This seems easiest to build.
> 
> There are other issues, of course, like choice of encoding and
> charset, but let's see what happens.

I had overlooked a number of others anonymity issues with MIME, which
you reminded me about on irc. For example, the choice of encoding
(base64, QP, ...) is another problem of MIME.

Summarizing --I think-- our discussion on irc, here is my next attempt
at a clarifying diff against the current specs. Comments and
corrections welcome.

Index: nym-spec.txt
===================================================================
--- nym-spec.txt	(revision 504)
+++ nym-spec.txt	(working copy)
@@ -673,8 +673,20 @@
    is prefixed with headers as in "E2E-spec.txt", but is otherwise
    unencoded.  When the server delivers the email, it adds a From
    line with the correct nym mailbox, and sets the name as given in
-   the headers.
+   the headers. In particular for email message delivery, the server
+   treats the BODY as a complete email message and injects it directly
+   in the local email transport system (e.g. the `sendmail' command or
+   a remote SMTP relay). MIME email relaying is discouraged at the moment.
+   Client implementations choosing to support them should warn the user about
+   anonymity problems with MIME and normalize them as much as possible, until a
+   proper MIME normalization suitable for anonymity applications is proposed.
 
+   At the very least, the following normalization of the MIME boundary
+   delimiters should be performed by the client: each delimiter is
+   chosen as a cryptographically random string in the set of strings
+   of length 42 bytes consisting only of ALPHA and DIGIT (in the
+   unlikely event of a boundary appearing in the parts, retry).
+
 4.3.6. GET [0x05]
 
    A GET command requests that the server transfer a set of emails to
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 483 bytes
Desc: Digital signature
Url : http://lists.noreply.org/pipermail/nym3-devel/attachments/20060323/9d17e25b/attachment.pgp