[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Quoted printable problem
From: |
David Levine |
Subject: |
Re: [Nmh-workers] Quoted printable problem |
Date: |
Sun, 11 May 2014 10:14:16 -0400 |
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