Re: Suggested Requirements for Multi-part Multi-Structured 822 Encoding

["Ned Freed, Postmaster" <[e-mail]>]

Sorry, I misspoke myself -- I gave the wrong reason why Dash-Count: can fail.
I implied that it had something to do with line wrapping. This is incorrect.

Dash-count: fails in the face of line truncation as opposed to line wrapping.
Yes, some mailers truncate rather than wrap. If the part of the line or lines
that gets truncated contains a dash, you're sunk.

Cookies are immune to truncation so long as they are short enough not to get
truncated. In practice they can be made short enough that this condition is
met in all reasonable situations.

It is also incorrect to characterize cookies as a two pass scheme. Properly 
implemented cookies are two pass in only a tiny percentage (literally one in 
3E38) of cases. If you generate a very random string for use as a cookie (for 
example, take the current date/time as a string, concatenate your system name 
and the message headers onto it, and run it all through the MD4 algorithm 
(RFC1186), finally representing the result using the base-64 encoding that's 
already part of the RFC, which gives you a 24 character string) you can just 
assume that it never appears in the message. Of course, to be on the safe side, 
you scan the message as you process it and look for the string (just on the off 
chance, although realistically the chances of your hardware failing are much 
greater than the chance that you'll find the string), and just start over if 
you do find it in there! This approach may in fact take many passes, but on
the average it takes one (and the standard deviation is, well, kinda small ;-).

Dash counting, on the other hand, always takes two passes. Every time.

					Ned