Problem emails

[cjsmall]

I'm running mutt 1.13.2 on an Xubuntu 20.04 system.

I have problems with certain base64-encoded emails. I've noticed that they often originate on MacOS machines. This one I'm discussing appears to have been generated in MacOutlook. From the header:

user-agent: Microsoft-MacOutlook/16.44.20121301

When I try to view the message in mutt, I just see the raw encoded body. When I press v and look at the attachments, mutt doesn't see any. this is what's reported on the attachment screen:

I 1 <no description> [text/plain, 7bits, 2.7M]

Something is ill-formed. When I save the entire email and run munpack on it, the eleven embed images are unpacked, but the text and html sections are not. Here is what munpack reports:

munpack: warning: Premature EOF
tempdesc.txt: File exists
image001.png (image/png)
image002.png (image/png)
munpack: warning: Premature EOF
image003.png (image/png)
image004.png (image/png)
image005.png (image/png)
image006.png (image/png)
munpack: warning: Premature EOF
image007.png (image/png)
munpack: warning: Premature EOF
image008.png (image/png)
image009.png (image/png)
image010.png (image/png)
image011.jpg (image/jpeg)
munpack: warning: Premature EOF

I'm no expert in mail format so I could use some help determining what's going on. Below is a representation of the email. I have replaced big sections with [[comments]] but left the Content-Type: blocks for examination. When you see a [[base64 comment] sitting directly above the --014_* closing line or with a blank line between, this is just how it appears in the message body. I suspect the missing blank lines are what's responsible for the "Premature EOF" warnings above.

Any ideas what's wrong with the message and why mutt and munpack cannot see the first two blocks? If I knew what was wrong, I might be able to sent my messages through a pre-delivery filter and fix it. Thanks for any insights.

Message:

[[Normal Email Header]]

--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: multipart/alternative;
boundary="_000_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_"

--_000_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

[[Base64 encoded text]]
--_000_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <***@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: base64

[[Base64 encoded html]]

--_000_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_--
--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=5563;
creation-date="Mon, 11 Jan 2021 20:01:50 GMT";
modification-date="Mon, 11 Jan 2021 20:01:50 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]

--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image002.png"
Content-Description: image002.png
Content-Disposition: inline; filename="image002.png"; size=1883;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]
--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image003.png"
Content-Description: image003.png
Content-Disposition: inline; filename="image003.png"; size=1824;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]

--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image004.png"
Content-Description: image004.png
Content-Disposition: inline; filename="image004.png"; size=2070;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]

--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image005.png"
Content-Description: image005.png
Content-Disposition: inline; filename="image005.png"; size=1671;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]

--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image006.png"
Content-Description: image006.png
Content-Disposition: inline; filename="image006.png"; size=5570;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]
--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image007.png"
Content-Description: image007.png
Content-Disposition: inline; filename="image007.png"; size=1892;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]
--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image008.png"
Content-Description: image008.png
Content-Disposition: inline; filename="image008.png"; size=1833;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]

--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image009.png"
Content-Description: image009.png
Content-Disposition: inline; filename="image009.png"; size=2079;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]

--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/png; name="image010.png"
Content-Description: image010.png
Content-Disposition: inline; filename="image010.png"; size=1680;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:51 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]

--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: image/jpeg; name="image011.jpg"
Content-Description: image011.jpg
Content-Disposition: inline; filename="image011.jpg"; size=2067743;
creation-date="Mon, 11 Jan 2021 20:01:51 GMT";
modification-date="Mon, 11 Jan 2021 20:01:52 GMT"
Content-ID: <***@01D6E82A.AFD83160>
Content-Transfer-Encoding: base64

[[Base64 encoded image]]
--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_--

[Eike Rathke]

Post by cjsmall
I 1 <no description> [text/plain, 7bits, 2.7M]
Any ideas what's wrong with the message and why mutt and munpack cannot see the first two blocks? If I knew what was wrong, I might be able to sent my messages through a pre-delivery filter and fix it. Thanks for any insights.
[[Normal Email Header]]
--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: multipart/alternative;
boundary="_000_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_"
[...]
--_000_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_--
--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_

Apparently the message has nested multiparts, does that "Normal Email
Header" contain a

Content-Type: multipart/...; ...;
boundary="_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_"

header? If not, that's the answer to why you're seeing only one
"attachment" and munpack just seems to get a boundary here from *within*
the text/plain stream.

Eike

[cjsmall]

Post by Eike Rathke
Apparently the message has nested multiparts, does that "Normal Email
Header" contain a
Content-Type: multipart/...; ...;
boundary="_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_"
header? If not, that's the answer to why you're seeing only one
"attachment" and munpack just seems to get a boundary here from *within*
the text/plain stream.

Thanks for the reply, Eike.

No, there is no Content-Type: line in the header. The first such line is in the body as shown above. The message seems to have gone through a Microsoft mail server and the following line is in the header, but it's not applicable:

x-ms-exchange-antispam-messagedata:
=?utf-8?B?VW1qYkxUb1c2aTF5REFRR2RtMDQ4eGFkUnRaZUpDRjdrOFZESjlNcVZHZmlM? =?utf-8?B?RWZpR295RCtuUno0ekttNmVJTnpOb2RpcXJ3QW1Vd29VS2NDNzFUQVhyVStI? =?utf-8?B?UFhPYTl3eWpyZlVkNmZ0c2swalIrdllKaWFvTEgvWXZhNm9PN1BvS0E5TEZV? =?utf-8?B?KzkySW02NVB0aWd1QWhMSUdQVWF0ZlV1TGRQWTYwUCsyRENhb285dU9oeDlU? =?utf-8?B?VUJuWUxROHlCaFMybU16WFR1Yys4R2o4Q2MyRmpoYzBkZTFzVGZXQlYvZlk1? =?utf-8?B?ZnlKNnVPOVBieTlzN1lUdGFjR2U3cHFxTTBxTmFlMGU1cjRMQ3ZkMTFzeXhh? =?utf-8?B?SkN4T2pJSjcyMHVYTTR6cGZUZDhzS3R1VFdjRVZRUWY5Q2FHNTlWR1J3SStv? =?utf-8?B?b1RWdVVLQkV4MldXQnRnZHQyTTU3OWNwelVIVS80bS9xMm1MQmU3NXExNWJC? =?utf-8?B?QXJBVEdmcjhrTnVCTThjRWlzVEJwYXZiMUx6Z0lWNzhOQTMxcWdTY2owaVVT? =?utf-8?B?YWdtOWtvMi9IWVlQRjlTMmUrTnhGUkFRb29PdytVaW5hcFJvM0s1Y05xT1NB? =?utf-8?B?akNGNG5HcVR2SmllVVhRVUxaSjNoK3NRVW1semVNOHdRNittOEhKYXNBTUkv? =?utf-8?B?c09WOTQ4NnVtV3NsVGxCT0c3dXcwWEZEeWFNNlV0SmZEcVZLTUh0QjhnMVVh? =?utf-8?B?WklEcTVZeFovQzJHVFNqYUFacm9rZW12SUdXTit5Y1NOY0hRS3RxZWtjbGFv? =?utf-8?B?WXpKRk16YlIxbGpqNlRERmdoaDdiSlUyNlNTNmNMNFBTbENGVFZSRXBCb3RV? =?utf-8?B?bHZabG03d2VBWEI1NEdDbmZ1S1BWalF6c3NGS2lBQVJiWWR4L0pVQ1ZJMTZs? =?utf-8?B?M2x1ajRWRUdONnpjZlJNVU9CV0xsTHlHZ2V3TVg3RUZHNmgyYmpVSFRFalIx? =?utf-8?B?LzhLSFlucnVRTW5yZ0lhVmpKY2VFcHhZNktBWlRLU2IrWkdkaS9tZjVVaFBt? =?utf-8?B?QmFxb1pOSzYvMEtaNG8rbTZiWUhzMEZ5Y3JzQUwzRm5rWFNiamdLWEYwUHJY? =?utf-8?B?U2pOckV5UDRuSE5HSjI3dk1zLzQ3dzhhVFpYLy9OUlk4OUJDQWlnd29WcmRh? =?utf-8?B?dTU4Q003UkVpdVBicENYQkF2SENPdUNleWIxL0JNSm9pNzgvVjU5WGJhUG92? =?utf-8?B?TGxsUkVTY3g5clcvY2pZQU8yOVNIeFNTdW9UQXkzdEtwKzl2SHhFRUw0M2I0? =?utf-8?B?aUtVbm8xdGpkL3ZnMm5NZFR4dlpxOWFXaFcyY2xjUnBWQ2xhUEVibUlTZFJ2? =?utf-8?Q?8hyfyw1KAK+py9GCQQq4dNiMX86FzJRQF1?Content-Type: multipart/related;
boundary="_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_";
type="multipart/alternative"

Any idea where the message is getting mangled? As I said, I've seen this problem from some other people using Macs, so is Apple doing something bad or could the header be getting screwed up by something like the Microsoft email server?

I also still don't understand why the image blocks can be munpacked but why the first two blocks are skipped. Since mutt doesn't show any attachments, does it just not look for them because the Content-Type: header line is missing?

[Eike Rathke]

Post by cjsmall
No, there is no Content-Type: line in the header.
[...]
=?utf-8?Q?8hyfyw1KAK+py9GCQQq4dNiMX86FzJRQF1?Content-Type: multipart/related;
boundary="_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_";
type="multipart/alternative"
Any idea where the message is getting mangled?

As it is directly following an x-ms-exchange-... header without CRLF you
could ask Microsoft.

Also, if it is already bad in the original data and not just due to
copy-pasting, that x-ms-... header content contains no CRLF pairs (or
any LF at all), likely just CR because hey it's Mac (you could determine
by inspecting the original data), so that might be another related
problem or even the underlying cause for no CRLF in front of the
Content-Type header.

Post by cjsmall
I also still don't understand why the image blocks can be munpacked but why the first two blocks are skipped. Since mutt doesn't show any attachments, does it just not look for them because the Content-Type: header line is missing?

Yes. No Content-Type multipart header = no multiparts.

Apparently munpack tries to guess boundaries from the text/plain content
on the fly.

Eike

[Peter Pearson]

On Mon, 11 Jan 2021 17:29:07 -0800 (PST), cjsmall wrote:
[snip]

Post by cjsmall
When I try to view the message in mutt, I just see the raw encoded
body. When I press v and look at the attachments, mutt doesn't see
any.

[snip]

Post by cjsmall
[[Normal Email Header]]
--_014_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_
Content-Type: multipart/alternative;
boundary="_000_38F8AFA1CFE745588061C7E41F3F7246fantiniusacom_"

Apologies if I'm just re-hashing stuff you already know. I'm no
authority on email formats, but I have looked at several, and it
seems to me that a properly formatted multipart message has
a line like this in the header:

Content-Type: multipart/alternative; boundary="some_boundary_string"

Thereafter, each "part" of the message begins with a block like this:

--some_boundary_string
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8

The last "part" ends with the boundary string followed by "--":

--some_boundary_string--

Can you find all these pieces in the offending message?