On 22Nov2016 03:27, vincent lefevre <vinc...@vinc17.org> wrote:
On 2016-11-20 18:51:25 +1100, Cameron Simpson wrote:
On 19Nov2016 19:58, Kevin J. McCarthy <ke...@8t8.us> wrote:
> References: =?utf-8?Q?=3C201611170549=2EQ3WT?=
> =?utf-8?Q?foMB=C3=83=C2=BEngguang=2Ewu=40i?=
> =?utf-8?Q?ntel=2Ecom=3E=20=3C1479410?= =?utf-8?Q?777-6702-1-git-sen?=
> =?utf-8?Q?d-email-manuel=2Esch?= =?utf-8?Q?oelling=40gmx=2Ede=3E?=
>
> <https://gist.github.com/andrey-utkin/c9cf4f2dc282cf257a2552b06ede49d5>
>
> If this is legal, then mutt needs to be decoding the References before
> trying to parse out the ids, because I believe it will just choke on
> this.
Wow. I would have thought that was illegal.
That's clearly illegal. MIME has been designed so that the main
features should still work with software that doesn't support MIME
(said otherwise, software that only needs to work with addresses
and Message-ID's does not need to support MIME).
Yeah. And reading the text of RFC2047 suggests that it is intended for Subject:
lines etc and explicitly _not_ for structured fields used by mail transport
agents, to avoid any need to rewrite the entire mail infrastructure.
Regarding the discussion below, the TL;DR is that I think that if it is
feasible mutt should decode these, but write _unencoded_ versions of these
headers and any headers derived from them. In particular, is it easy to make
mutt's header ingestion code go "stict parse, but if that fails decode with
RFC2047 and try a second time"? Probably on a specific header basis.
I don't think that Mutt should even try to support these. This could
lead to various problems. First, what to do with characters that are
illegal (e.g. non-ASCII) in a Message-ID...
I think mutt should cope with them to the extend of decoding them and including
them in the message thread stuff. I think any generated headers such as
in-reply-toand references in new messages should not contain these. I'd argue
(as one not actually writing the code:-) that the ingest should learn to decode
these for threading (thread on the decoded strings, should that be needed) and
when writing message-ids to new headers mutt should syntax check those strings
and discard invalid ones (for added points, shunt them to an
x-discarded-invalid-message-ids header:-)
Regarding non-ASCII, we decode to bytes. Valid message-ids only contain ASCII
anyway. If mutt ingests and decodes this rubbish, it can write out clean _not_
encoded message-ids for those which are syntacticly clean, making for a
healthier ecosystem.
Cheers,
Cameron Simpson <c...@zip.com.au>
Television is an invention that permits you to be entertained in your living
room by people you wouldn't have in your home. - David Frost
