[art] Re: email: message/rfc822 (RFC 2046) MIME parts are defunct

[Nathaniel Borenstein <[e-mail]>]

*    Nathaniel, any additional or contradictory thoughts?*

Not really.  A cleanup is undoubtedly a good idea.  However, it has been
years since I was intimately involved with day-to-day email management, so
I have no real insight into what is common practice these days.  Neither do
I have the time to get deeply involved in such an effort, though I will
read any discussions and contribute if I have something to add.

It seems like there's a larger problem here.  If IETF work is primarily
done nowadays by people working in the interests of their employers, who is
sufficiently motivated to put the work into a cleanup like this?  --
Nathaniel


On Mon, Jul 27, 2026 at 6:42 PM John C Klensin <[e-mail]> wrote:

> Steffen,
>
>
> --On Monday, July 27, 2026 22:19 +0200 Steffen Nurpmeso
> <[e-mail]> wrote:
>
> > Hello.
> >
> > Via some DKIM mail exchange i was reminded of a finding that was
> > not reported anywhere, as far as i know.  I would not know how to
> > proceed anywhere else.
> >
> > The problem is that RFC 2046 has a technical deficit in that it
> > defines for message/rfc822 MIME parts (attachments) only the
> > content-transfer-encodings 7bit, 8bit, and binary (whatever this
> > actually is).
>
> Ok. The spec is showing its age.   FWIW, I see rather little use of
> message/rfc822 or of multipart/digest (which requires it).  Section
> 5.2.1 of RFC 2046 is also quite clear that conformance to RFC 822 is
> not required and I read that section as implying that headers
> introduced with 5322bis or intervening specs are just fine.  And it
> does also point to RFC 2047 for non-ASCII header fields.    I do see
> a couple of problems here, see below.
>
> > This (effectively) means it puts trust in the correctness of the
> > data that is stored via message/rfc822.
> > But this might not be the case.
>
> I'm not sure what you are suggesting.  Absent some sort of
> signatures, I don't know why one would especially "put trust" in any
> MIME body part.
>
> > I know of two MUA implementations, one this year has its 30
> > anniversary, and is the most widely used console based MUA in the
> > UNIX world, used heavily by all kind of developers -- all that as
> > far as i know -- which follow this advice of RFC 2046 exactly, by
> > having special code paths, and not performing deep data inspection
> > beyond the "high-bit-set" kind of thing.
> > I would expect most other software to likewise honour the RFC,
> > message-preparation-wise.
> >
> > One can send with that software emails with message/rfc822
> > attachments which will be misinterpreted by the software itself.
> > (Thus.)  Also obeying stricter parsing rules as of POSIX or RFC
> > 4122 do not change the overall problem.  (If used at all.)
> >
> > That is to say that even an "errata" that states that other
> > content-transfer encodings (base64 and quoted-printable, say) may
> > be used will take a lot of time to be implemented and distributed.
> > And MIME parts created with such an updated definition may not be
> > interpreted correctly by elder software, anyway.
>
> Right.  Partially for those reasons, I'd assume that an errata as you
> suggest would be marked for "Hold for Document Update", which would
> do no good at all.  See below.
>
> > I want to point out that at least the elder Mailman2 mailing-list
> > manager, which "drove my perceived email world", offers DMARC
> > mitigations which turn messages into such attachments.
> > And that it can optionally create MBOX databases which store the
> > entire history of a mailing-list.  (I myself make use of that.)
> > The underlaying problem as such is known to cause failures even in
> > the most modern software (like "public inbox").
> >
> > For the software i maintain the next release will perform deep
> > inspection and turn such message/rfc822 into text/plain with an
> > .eml filename, and a proper content-transfer-encoding.
> > This is a hack.
>
> A hack, but a plausible one.
>
> > What could be done, i do not know.  A new message/5322 or what,
> > and with deep-inspection and any content-transfer-encoding, as
> > desired, maybe.  Reencoding message content as such is for one
> > a complicated task that only few codebases would be capable to
> > perform properly for one, and it also changes any signature, of
> > whatever sort.
>
> >...
>
> Well, from my point of view, this seems to call for an update to RFC
> 2046.  That might either
>
> * expand the definition of text/rfc822 to allow for 8BITMIME and
> probably get rid of the RFC 2047 reference and replace it with a
> discussion and pointer to the SMTPUTF8 specs (or keep it and explain
> and supplement it with such a reference.
>
> * or introduce a new media type (along the lines of message/rfc5322
> although I'd hope for a name that would not tie us to a particular
> version of the header spec, maybe message/imf or the like.  That
> option would probably require tuning the definition of
> message/digest, etc., as well.
>
> I think the main obstacles to either would be someone volunteering to
> do the work.  One might ask MEDIAMAN or MAILMAINT to take it up, have
> a conversation with an appropriate AD, or plan on a DISPATCH effort
> for the next IETF.
>
> I'd personally love to see an update to the MIME specs to do some
> housekeeping and bring them to Internet Standard. Those documents
> have held out remarkably well in the 30 years since they were
> published but I'm guessing that, if you or others looked carefully,
> you'd find other things in need of be tuning by now.  I'd also be
> very happy to see an Applicability Statement that would cover the
> range of important and/or heavily used media types, giving whatever
> advice was approach.  However, I have no idea how such an effort
> would be structured and, given the difficult experience with
> draft-ietf-emailcore-as, I have trouble imagining anyone wanting to
> sign up to do the work.  An update to deal with evolution from some
> of the definitions on RFC 2026 feel much more realistic.
>
> Nathaniel, any additional or contradictory thoughts?
>
>   best,
>    john
>
>
>
>
>