Re: MTS transparency and anonymity

In <[email protected]> Bruce Lilly <[email protected]> writes:

>So far as I can see, there is no perfectly clean solution to the
>issues covered in the draft.

Agreed.

>  However, simply making the From
>field optional -- while that may present some issues -- seems to
>have the least negative impact of the options considered (including
>syntax changes and extension, which present rather more serious
>backwards compatibility issues than making the field optional).

But I don't think you have established that at all.

>A syntax change to permit "From: <>" or named group syntax "From:
>phrase: (possibly empty) list;" would have the desired semantics,
>but appears to have more serious backwards compatibility issues
>than making the field optional;

Nor that.

The concern is that whatever solution we adopt may have some negative
impact on the installed base (clearly, future implementations could be
made to cope with any of them).

There are four solutions that have been proposed:

1. Omit the From field entirely
2. Use some invalid domain, e.g. @blah.invalid.
3. Use some invalid IP, e.g. @[] or @[0,0,0,0]
4. Introduce some new syntax, e.g. From: "Mickey Mouse" <>

The requirements for acceptable impact on the installed base are:

A. The message (once past the initiating MUA and submission agent) must be
   delivered reliably to its intended destination, and, when so delivered,
   should be unaltered.

B. The message must be unreplyable, and the failure to reply should be
   done gracefully.

So we can consider how those requirements are met in the 4 cases:


                1. No From      2. blah.invalid 3. @[]          4. From <>

A. delivery     98% [1]         100%            98%             98%

   unaltered    maybe not [2]   100%            98%             90% [3]

B. replyable    possibly [2]    2% [1]          2%              0%	

   graceful     Yes             maybe [4]       maybe [5]       probably [6]

NOTES:

[1] 98% means I find it inconceivable that any current system would drop
    the whole message on the floor or change it in any way.

    2% means I find it inconceivable that any current system would
    construct a deliverable reply.

[2] It is known that some systems DO insert a (supposedly plausible) From
    field, and these are quite likely to be replyable (though not
    necesarily to the original sender).

[3] It is possible that a syntactically invalid from field would be
    dropped, or changed into some X-field. That is probably an acceptable
    behaviour, particularly if it only happens at the final MUA.

[4] If DNS failures are not cached (as they should be), then there will be
    some load on the root servers.

[5] The treatment of supposedly 'safe' IPs, such as [0,0,0,0],
    [127,255,255,255] might be somewhat bizarre. [127,0,0,1] might even be
    delivered, but hopefully to the person replying.

[6] I think a core dump on attempting to reply is most unlikely, but the
    error message produced might be less than helpful.


Clearly, this analysis shows that no solution is going to be perfect (but
we knew that already). OTOH, it does seem to shown that #1 has worse
problems than the others.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email protected]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5