Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Is it okay to have Base64 encoded MIME sections without the proper Content-Type* headers?

11 views

Skip to first unread message

Grant Taylor

unread,

May 23, 2018, 11:18:36 PM5/23/18

Is it okay to have Base64 encoded MIME sections without the proper
Content-Type* headers?

I am working with a message much like the one below * where there is a
MIME section that does not have either the Content-Type: or
Content-Transfer-Encoding: headers and instead is just raw base64
encoded content.

Notice that the expected Content-Type: and Content-Transfer-Encoding:
headers are inside of the base 64 encoded text, not outside like I would
expect.

I think this is an abomination, but I don't know enough about MIME to
say one way or the other.

Claus Aßmann replied to a post in comp.mail.sendmail suggesting that I
post my question here in comp.mail.mime.

+--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
|To: us...@example.org
|From: us...@example.org
|Date: Wed, 23 May 2018 20:36:46 -0600
|Subject: Re: Testing...one...two...three...
|Content-Type: multipart/mixed;
| boundary="--MIME-Boundary"
|Content-Transfer-Encoding: 7bit
|
|This is a multi-part message in MIME format.
|--MIME-Boundary
|Content-Type: text/plain; charset=utf-8; format=flowed
|Content-Transfer-Encoding: 7bit
|
|Yes, I did get your test message.
|
|Thank you for sending it.
|
|I'm attaching what I received.
|
|--MIME-Boundary
|Q29udGVudC1UeXBlOiBtZXNzYWdlL3JmYzgyMjsKCW5hbWU9IkF0dGFjaGVkIE1lc3NhZ2UiCkNv
|bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKQ29udGVudC1EaXNwb3NpdGlvbjogYXR0YWNo
|bWVudDsKCWZpbGVuYW1lPSJBdHRhY2hlZCBNZXNzYWdlIgoKVG86IHVzZXIyQGV4YW1wbGUub3Jn
|CkZyb206IHVzZXIxQGV4YW1wbGUub3JnCkRhdGU6IFdlZCwgMjMgTWF5IDIwMTggMjA6Mjk6NDQg
|LTA2MDAKU3ViamVjdDogVGVzdGluZy4uLm9uZS4uLnR3by4uLnRocmVlLi4uCkNvbnRlbnQtVHlw
|ZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYtODsgZm9ybWF0PWZsb3dlZApDb250ZW50LVRyYW5z
|ZmVyLUVuY29kaW5nOiA3Yml0CgpUaGlzIGlzIGEgdGVzdCBtZXNzYWdlLgoKRGlkIHlvdSBnZXQg
|aXQ/Cg==
|--MIME-Boundary--
|
+-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8--

Here's the decoded version of the above base 64 encoded contents.

+--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
|Content-Type: message/rfc822;
| name="Attached Message"
|Content-Transfer-Encoding: 7bit
|Content-Disposition: attachment;
| filename="Attached Message"
|
|To: us...@example.org
|From: us...@example.org
|Date: Wed, 23 May 2018 20:29:44 -0600
|Subject: Testing...one...two...three...
|Content-Type: text/plain; charset=utf-8; format=flowed
|Content-Transfer-Encoding: 7bit
|
|This is a test message.
|
|Did you get it?
|
+-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8--

Remove cut lines and the leading "|" character.

--
Grant. . . .
unix || die

Eli the Bearded

unread,

May 26, 2018, 6:00:19 PM5/26/18

In comp.mail.mime, Grant Taylor <gta...@tnetconsulting.net> wrote:
> Is it okay to have Base64 encoded MIME sections without the proper
> Content-Type* headers?

In theory, I suppose, base64 is compatible with plain text and could go
anywhere that plain text goes, but without headers to indicate it is
base64, you cannot count on readers to decode the content and instead
will show it as base64, which is usually Not Ideal.

> I am working with a message much like the one below * where there is a
> MIME section that does not have either the Content-Type: or
> Content-Transfer-Encoding: headers and instead is just raw base64
> encoded content.

I concur with your (now snipped) comment that this is an abomination.

This breaks RFC2046 section 5.1.

http://www.faqs.org/rfcs/rfc2046.html

5.1. Multipart Media Type

In the case of multipart entities, in which one or more different
sets of data are combined in a single body, a "multipart" media type
field must appear in the entity's header. The body must then contain
one or more body parts, each preceded by a boundary delimiter line,
and the last one followed by a closing boundary delimiter line.
After its boundary delimiter line, each body part then consists of a
header area, a blank line, and a body area. Thus a body part is
similar to an RFC 822 message in syntax, but different in meaning.

A body part is an entity and hence is NOT to be interpreted as
actually being an RFC 822 message. To begin with, NO header fields
are actually required in body parts. A body part that starts with a
blank line, therefore, is allowed and is a body part for which all
default values are to be assumed. In such a case, the absence of a
Content-Type header usually indicates that the corresponding body has
a content-type of "text/plain; charset=US-ASCII".

That example lacks the blank line required to separate the boundary +
section headers from the section body. And the content, being base64
encoded, lacks the required syntax to make it a RFC822 compliant header
field.

Elijah
------
future RFCs have not backed away from the blank line requirement

0 new messages