Re: Bogusly RFC2047'd "inline" for Content-Disposition
(Merging replies to two related items) On Sat, 26 Sep 2020 00:14:59 +0100, Conrad Hughes said: > Just saw this for the first time: > > Content-Disposition: =?utf-8?Q?inline?= I can do you one better.. In my folder of broken mail that gives exmh heartburn, I found this one back in 2016: X-Mailer: =?UTF-8?B?dGlwLWdpdC1sb2ctZGFlbW9u?= Robot-ID: =?UTF-8?B?PHRpcC1ib3QuZ2l0Lmtlcm5lbC5vcmc+?= Robot-Unsubscribe: =?UTF-8?B?Q29udGFjdCA8bWFpbHRvOmhwYUBrZXJuZWwub3JnPiB0byBnZXQgYmxhY2tsaXM=?= =?UTF-8?B?dGVkIGZyb20gd Ghlc2UgZW1haWxz?= MIME-Version: =?UTF-8?B?MS4w?= Content-Transfer-Encoding: =?UTF-8?B?OGJpdA==?= Content-Type: =?UTF-8?B?dGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOA==?= Content-Disposition: =?UTF-8?B?aW5saW5l?= Fortunately for all concerned, *that* bot was fixed within a few hours. Unfortunately, it looks like in *this* case, we may be waiting for a while for it to actually be fixed out in the wild - looks like the fix to force the Content-Disposition: tag was merged in Dec 2019, and we're just hearing about the problem now in almost-October 2020. On the other hand, that also tells me that Magento's market share must not be very large if nobody noticed. I've poked the relevant IETF lists about the details on this On Sat, 26 Sep 2020 09:45:20 -0400, David Levine said: > It looks like the problem has been fixed. We could teach mhfixmsg to > fix this, though I'm inclined not to do that unless this turns out to be > a more widespread problem. Given that I've only seen this sort of silliness twice this century, I'd say the risks of adding code to mhfixmsg probably outweigh the need to extend it. And although there's "Be liberal in what you accept", that's not really scalable with stuff that's flat-out broken - especially if it doesn't generate pushback to get the broken stuff fixed. pgp59Gsuf_ZZd.pgp Description: PGP signature
Re: Bogusly RFC2047'd "inline" for Content-Disposition
Date:Sat, 26 Sep 2020 17:09:36 +0100 From:Ralph Corderoy Message-ID: <20200926160936.7311722...@orac.inputplus.co.uk> | that field does not parse so RFC 2183's How do you know for sure? In this case it seems unlikely, but any string could be "An extension token defined by a standards-track RFC and registered with IANA" The code certainly isn't going to go look in the IANA registry to see if some unknown string is registered there or not, all it is possible to do is assume that it might have been. kre
Re: Bogusly RFC2047'd "inline" for Content-Disposition
Ken wrote: > according to the first bug report it broke things > for Thunderbird and Exchange/Outlook, so I think this is something that > should be fixed rather quickly. As in fixed at the source? It looks like it already has been. As far as nmh goes, I hacked up a message with that bogus Content-Disposition and I was still able to mhshow it. That might depend on my profile settings. I just ignored the warning. Worst case, nmh users should still be able to mhstore the content and view it. David
Re: Bogusly RFC2047'd "inline" for Content-Disposition
>> > Content-Disposition: =?utf-8?Q?inline?= >... >> It seems, however, we should simply follow RFC 2183 and treat it as an >> "unknown" disposition (which means "default as attachment"). > >I disagree. :-) I understand where you're coming from given a strict reading of the ABNF, but ... it's not clear to me what's supposed to happen if you fail to parse that header. I know some people think that nmh should execute "rm -rf /" if it ever sees an invalid message (not really, but it sure seems like it sometimes), but we're alone in MUAs in our refusal to process messages when we hit something invalid. I would argue that the "unknown" disposition covers the "cannot parse disposition" case. --Ken
Re: Bogusly RFC2047'd "inline" for Content-Disposition
Hi Ken,
> > Content-Disposition: =?utf-8?Q?inline?=
...
> It seems, however, we should simply follow RFC 2183 and treat it as an
> "unknown" disposition (which means "default as attachment").
I disagree. :-)
Given RFC 2183's grammar,
disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)
disposition-type := "inline"
/ "attachment"
/ extension-token
; values are not case-sensitive
coupled with RFC 2045,
extension-token := ietf-token / x-token
ietf-token :=
x-token :=
that field does not parse so RFC 2183's
Unrecognized disposition types should be treated as `attachment'.
does not apply as we do not have a disposition type, recognised or not.
--
Cheers, Ralph.
Re: Bogusly RFC2047'd "inline" for Content-Disposition
>Looks like it was Magento, using Zend Framework 2/Laminas: >https://github.com/magento/magento2/issues/29258 >https://github.com/laminas/laminas-mail/issues/2 > >It looks like the problem has been fixed. We could teach mhfixmsg to >fix this, though I'm inclined not to do that unless this turns out to be >a more widespread problem. It's up to you, David, but according to the first bug report it broke things for Thunderbird and Exchange/Outlook, so I think this is something that should be fixed rather quickly. --Ken
Re: Bogusly RFC2047'd "inline" for Content-Disposition
Ken wrote: > Ooof. That's a MAJOR "do not do". Also, it seems like we wouldn't be > the only ones who break on that! I'm wondering what broken code generates > THAT. It seems, however, we should simply follow RFC 2183 and treat it > as an "unknown" disposition (which means "default as attachment"). Looks like it was Magento, using Zend Framework 2/Laminas: https://github.com/magento/magento2/issues/29258 https://github.com/laminas/laminas-mail/issues/2 It looks like the problem has been fixed. We could teach mhfixmsg to fix this, though I'm inclined not to do that unless this turns out to be a more widespread problem. David
Re: Bogusly RFC2047'd "inline" for Content-Disposition
>Just saw this for the first time: > > Content-Disposition: =?utf-8?Q?inline?= > >.. causing "mhshow: extraneous information in message 126's >Content-Disposition: field (=?utf-8?Q?inline?=)". As far as I can see >this is a MUST NOT do, but probably not too hard to accept and DTRT. Ooof. That's a MAJOR "do not do". Also, it seems like we wouldn't be the only ones who break on that! I'm wondering what broken code generates THAT. It seems, however, we should simply follow RFC 2183 and treat it as an "unknown" disposition (which means "default as attachment"). --Ken
Bogusly RFC2047'd "inline" for Content-Disposition
Just saw this for the first time: Content-Disposition: =?utf-8?Q?inline?= .. causing "mhshow: extraneous information in message 126's Content-Disposition: field (=?utf-8?Q?inline?=)". As far as I can see this is a MUST NOT do, but probably not too hard to accept and DTRT. Thoughts? Conrad
