"Anthony J. Bentley" writes:
I'm guessing this is a bug in the MARC.info software, and I sent a bug
report to the operators. But in the interest of pragmatism, would it
make sense for nmh to pick a boundary value that is less likely to
trigger bugs in other software?
By this I mean something without spaces, equals, and double quotes.
(I don't know specifically which of these causes the MARC.info bug.)
For example, GMail uses 28-character hex numbers, like
0016e68fcec4ab7a4004b3f7d05a.
As a point of note ... the double quotes are technically not part of
the boundary; they're quotes around the MIME parameter. MH and nmh have
always quoted MIME parameters on output; you don't have to quote MIME
parameters if they fall under a restricted grammar (technically, if
it doesn't contain a space, control, or "tspecial" character), but
to be safe we always always quoted parameters. I'd rather not change
that, because then we'd have to quote parameters conditionally and
that's a place to get things wrong (also, unnecessary complexity).
A quick look through my mailbox shows that = is very common in a
boundary, but spaces are rare (I only found one email that wasn't from
an MH or nmh user that contained a space in the multipart boundary), so
I suspect that's the thing that is causing the problem.
But ... the part of me that is a grumpy reactionary is unhappy about
changing the MIME boundary to deal with broken software. A space in
the boundary is valid (this is an example in RFC 2046), and MH has had
that for 20+ years. Everyone ELSE on the planet can deal with that just
fine; if it was causing lots of problems I'd be more open to it, but
clearly it is not. Also, given the lead time for nmh releases it would
probably be a year or two before that made it into distributions. There
is special handling to deal with the MIME boundary because we check
encapsulated content to make sure it doesn't appear inside of parts and
we then adjust it accordingly, but the biggest pain would be changing
the test suite to deal with it. My gut feeling is the answer should be
"no" and we should contact the appropriate people to get those problems
fixed.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers