nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] another MIME failure, this time it's the C-T


From: Ken Hornstein
Subject: Re: [Nmh-workers] another MIME failure, this time it's the C-T
Date: Wed, 19 Dec 2012 23:11:41 -0500

>Probably.  I was able to view the enclosed PDF.
>
>I have a request out for the orginal msg--to figure out the mega-bozo MUA, FYA.

As a follow-up ...

Like I said, RFC 2045-2046 are mum about what to do with an unknown top-level
Content-Type (as far as I can tell).  But the precessors to those RFCs
actually were more explicit.  From RFC 1521, section 4:

   When a mail reader encounters mail with an unknown Content-type
   value, it should generally treat it as equivalent to
   "application/octet-stream", as described later in this document.

The documents got shuffled around a lot between revisions and the list of
MIME types in RFC 1521 got moved to their own RFC (2046).

Ah-HA, okay, so that particular stuff got moved to RFC 2049.  Section 2(7):

    (7)   Upon encountering any unrecognized Content-Type field,
          an implementation must treat it as if it had a media
          type of "application/octet-stream" with no parameter
          sub-arguments.  How such data are handled is up to an
          implementation, but likely options for handling such
          unrecognized data include offering the user to write it
          into a file (decoded from its mail transport format) or
          offering the user to name a program to which the
          decoded data should be passed as input.

So yeah, file/pdf is mega-bozo, but we should have handled it as
application/octet-stream.  Looks like that needs fixing.

--Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]