Paul F. wrote: > david wrote [on 5 Jan 2013!!]: > > Ralph wrote: > > > > > Hi Ken, > > > > > > > Maybe changing the error message a bit would be useful? > > > > > > Yes, I agree with David's suggestion. Options include: state the RFC > > > bit being violated so the user can cite it at the miscreant; suggest > > > how the user edit the email to workaround; refer the user to a bit of > > > the documentation that explains the issue in more detail, including the > > > previous two. > > > > I committed an expanded message with those first two options. > > For the original message that started this thread: > > > > mhshow: "multipart/mixed" type in message 1497 must be encoded in > > 7bit, 8bit, or binary, per RFC 2045 (6.4). One workaround is to > > manually edit the file and change the "QUOTED-PRINTABLE" > > Content-Transfer-Encoding to one of those. For now, continuing... > > > > where the quoted strings and message number/filename are variable. > > the trouble with the message is that, at least in the cases of > mhshow and mhlist, the program doesn't continue. it quits. i guess > that's the goal, but seems like using advise() or even adios() would > be better, to avoid the false hope given by "continuing..."
Maybe they would continue on to the next multipart, if there was one? > i just hit one of these, where the multipart/alternative header had > a c-t-e of quoted-printable. it was from wordpress.com. is that where > the other recent instance was from? > > i confess i'm more on the side of "chastise and continue" for things > like this, rather than "scold and quit". are there other strict > checks in the codebase? could we add a profile setting that could > be used to change the behavior to "continue"? I get maybe two or three of these a year. For me, it's not worth adding support for a profile setting. And I prefer the current behavior. All of the admonish/advise/adios messages and conditions should be reviewed. There are a lot of them. In any case, I don't want to be in the business of deciding whether failure to pass a strict check might possibly allow a harmful message to pass. David _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
