Subject: RFC 2183: Unparseable Content-Disposition Field.

From: Ralph Corderoy <[email-masked]>
Date: Sat, 26 Sep 2020 17:42:51 +0100

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,

    Content-Disposition: =?utf-8?Q?inline?=

is being seen on real-life emails due to a bug.

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 := <An extension token defined by a
                    standards-track RFC and registered
                    with IANA.>

     x-token := <The two characters "X-" or "x-" followed, with
                 no intervening white space, by any 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.

- Am I missing something in RFC 2183 which describes what to do in that
  case?
- Is there an overarching clause in another email RFC which says
  something like an field which does not parse is considered to not
  exist?

-- 
Cheers, Ralph.

---

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 ]

>    Content-Disposition: =?utf-8?Q?inline?=

Yuck.  But I can believe it.

> - 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.

>  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

> 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)