Re: [Nmh-workers] default Content-Type boundary value?

[Ken Hornstein]

>If I had to guess, I'd guess the leading dashes (hyphens, minus signs, 
>whatever...) - it would be easy for broken software to simply skip all
>leading -'s after looking for the leading two that always precede the
>boundary marker in the body.   The spaces would be my next guess (assuming
>the marker to be one "word").

FWIW, in my super-unscientific survey of multipart boundaries, hypens
(even leading ones) were actually fairly common.  Spaces were not.

>ps: incidentally I agree with not changing things to cope with broken
>software, but in the interests of best compatibility, and recognising that
>the standards are supposed to specify what actually works (and so a revision
>to it might outlaw usages that are known to break things), and following
>the general MH philosophy that *everything* is configurable, perhaps adding
>a profile setting with a pattern for the boundary string (which would be
>modified in some specified way to account for clashes, and the need for
>more than one in a message) would be a reasonable choice ... then people
>who know they're sending to something broken could change the default.
>Alternatively (and slightly less flexibly) a profile entry to allow the
>user to pick one of a small predefined set of boundary styles.

Sigh.  I took a closer look at this, and it's not as complicated
as I thought.  Literally, it's just the definition of "prefix" in
uip/mhbuildsbr.c.  Making it configurable might be more than I
personally want to do, however.  So I'm willing to relax my earlier
stance regarding changing it ... but I'd like some understanding as
to what's wrong with it.  Changing it because we _think_ we know what's
wrong doesn't make sense to me.  If someone else wants to write code
making prefix configurable, speak up.  Changes to the prefix would
also be accepted, but they have to include fixes to the test suite.

--Ken