>Well, whether you intentionally type any and whether some happen to creep >into your email are two different things. As an example: I am suspicious >now that my problem really stemmed from exmh choosing to use both -push >and -forward; the latter is documented as "If -forward is given, then a >copy of the draft will be attached to this failure notice." So I am >thinking that it stuck the UTF8-containing text onto the failure notice, >and then that send attempt failed for exactly the same reason, ie it was >rejected by the character set strictness check. Even if you're right that >there was no send attempt at all, I'm expecting that once it's there >it will fail like this :-(
Well, I looked. It's important to understand the workflow here, and how things have evolved over time. First, you have to have special handling to handle -push in send; I didn't implement that for mhbuild. So yeah, mhbuild failing and not sending a notification email is a bug. At least if that had worked, you would have gotten something in dead.letter if it couldn't send it. So, current workflow. A user creates a "draft file" by whatever means. Then it gets passed to send(1). send's job is to turn the draft file into a RFC 5322-compliant message and then send it to post(8). That is done by calling mhbuild(1) on the draft. This used to be optional; the result was that nmh users could very easily be sending out messages that weren't MIME compliant (and that happened a lot). >So basically the problem here is one of robustness. Yeah, it would be >nice to be sure that what you are sending is 100% valid. But I don't >really agree with the tradeoff that's been made of failing when you >can't be sure of that. Especially since, if you think you know what >non-ASCII encoding a bit of text is in, you're just fooling yourself >anyway. It's impossible to distinguish the ISO 8859 variants from >each other, and at best heuristic to tell whether text is in UTF-8 >or an ISO 8859 variant. I agree that we can't reasonably know what the character set is supposed to be in that case. But I would say that given the choice between sending 'something wrong' and 'erroring out', 'erroring out' is the more correct option. But I would be interested in hearing what other people think. >Maybe we could just leave off the character set spec if it turns out to >be definitely wrong? As Ralph pointed out, that means the same as us-ascii ... and we know that's wrong. Before, it looks like we would generate a character set of x-unknown; I'm not in love with that either. Really, it seems like this exposes something wrong that the user should correct. Also, if your forwarding messages with 8-bit characters, you should really be using forw -mime. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
