On Thu, Sep 02, 2010 at 05:10:37PM -0700, Michael Elkins wrote:
On Thu, Sep 02, 2010 at 07:20:18PM -0400, Ed Blackman wrote:
I forwarded the message I copied the headers from, along with a one
that had spaces in the encoded-text, to my work Outlook and to my
Gmail account. Both Outlook and
On Mon, Sep 06, 2010 at 10:27:24PM -0400, Ed Blackman wrote:
I've been running all weekend with this patch. It works for both
unencoded ? and SPACE characters in RFC2047 header lines. I
searched my mail corpus for RFC2047 encoded headers (both strictly
conformant and non-conformant), and
I've been seeing more and more =?US-ASCII?Q?...?= in email Subject
lines lately. At first, it was all from a particular (and not very
technically apt) source, and I assumed that they were doing something
wrong, and more or less ignored it. But as I get emails from more and
more sources, it's
On Thu, Sep 02, 2010 at 04:39:23PM -0400, Ed Blackman wrote:
I did a little searching and found that RFC 2047 is the technical
specification for these encoded strings, and that mutt does have RFC
2047 support. However, none of the muttrc entries that mention it
seem relevant to RFC 2047
On Thu, Sep 02, 2010 at 02:49:00PM -0700, Michael Elkins wrote:
The problem is that the sender's MUA has not produced a valid RFC2047
encoding. Here is the ABNF (RFC2047, section 2, Syntax of
encoded-words):
Conincidentally, it appears that even Twitter doesn't get this right. From an
On Thu, Sep 02, 2010 at 03:11:30PM -0700, Michael Elkins wrote:
On Thu, Sep 02, 2010 at 02:49:00PM -0700, Michael Elkins wrote:
The problem is that the sender's MUA has not produced a valid RFC2047
encoding. Here is the ABNF (RFC2047, section 2, Syntax of
encoded-words):
Conincidentally,
On Thu, Sep 02, 2010 at 07:20:18PM -0400, Ed Blackman wrote:
Does mutt rely on the fact that encoded-text shouldn't have ? or
SPACE because it makes the implementation easier? Or is it just
following the RFC strictly? Reading the RFC, it's not clear to me
*why* encoded-text can't have ? or
