Subject: Re: [ietf-822] RFC 2183: Unparseable Content-Disposition Field.

From: "John R. Levine" <[email-masked]>
Date: 26 Sep 2020 15:25:42 -0400

[ replies directed to ietf-822 which is more germane to this topic ]

On Sat, 26 Sep 2020, Ralph Corderoy wrote:
>    Content-Disposition: =?utf-8?Q?inline?=

Yuck.  But I can believe it.

> does not apply as we do not have a disposition type, recognised or not.
>
> - Am I missing something in RFC 2183 which describes what to do in that case?

No, IETF standards generally tell you how to interoperate with other 
people who implement the standards, on the perhaps optimistic assumption 
that they will read the specs and follow them, not how to work around 
breakage.

> - Is there an overarching clause in another email RFC which says
>  something like an field which does not parse is considered to not exist?

There are a few cases where we've said things like that, e.g., an invalid 
DKIM signature is equivalent to no DKIM signature, but in general trying 
to guess what someone meant when they do something invalid is hopeless.

Or to look at it another way, if a sender doesn't care enough to say 
correctly what they would like me to do with their mail, I don't care 
enough to try to guess what they might have meant.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Sep 2020 12:38:35 -0700

>  something like an field which does not parse is considered to not exist? 

IETF specifications vary in their directions about the handling of 
non-conformance.  Sometimes ignore.  Sometimes reject.  Etc.

Specifications define the boundaries of a sandbox and anyone choosing to 
be inside the sandbox needs to be conformant.  If they aren't, they 
aren't really inside.

The Postel rule is often taken as permission to do whatever you want, 
but, really, it was meant to cover plausible cases of non-conformance, 
allowing for possible ambiguities (or even errors) in a specification.

Your reasonable interpretation might be different than someone else's 
reasonable interpretation, and it might be helpful to have your protocol 
engine show some empathy for the alternative interpretation.

It also might not.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Sat, 26 Sep 2020 18:08:03 -0400

On Sat, 26 Sep 2020 17:42:51 +0100, Ralph Corderoy said:
> Hi,
>
> https://www.rfc-editor.org/rfc/inline-errata/rfc2183.html says what to
> do if the disposition type is unrecognised, but not what to do if the
> Content-Disposition field does not parse.  For example,
>
> is being seen on real-life emails due to a bug.

Ralph: Can you confirm/deny the datestamp on the mail you saw this on?

On another mailing list, it was attributed to the Magento/Zend mailer software,
but various fixes to those packages were made all the way back in Dec 2019. So
before devoting much resources to it, we should confirm whether the cause has
repented and changed their ways, or if somebody needs to update their system,
or something else is going on...

(Back in 2016, there was a bot that encoded many of the headers using
=?utf-8?B?...  encoding, but that one got fixed within a few hours)