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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers