• Is it okay to have Base64 encoded MIME sections without the proper Cont

    From Grant Taylor@21:1/5 to All on Wed May 23 21:19:23 2018
    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: user1@example.org
    |From: user2@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--

    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: user2@example.org
    |From: user1@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--

    Remove cut lines and the leading "|" character.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli the Bearded@21:1/5 to gtaylor@tnetconsulting.net on Sat May 26 22:00:19 2018
    In comp.mail.mime, Grant Taylor <gtaylor@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.

    +--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
    |To: user1@example.org
    |From: user2@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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)