1. Forum
  2. Usenet
  3. COMP.MAIL.MUTT

  • Problem emails

    From cjsmall@21:1/5 to All on Mon Jan 11 17:29:07 2021
    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_"

    [[Base64 encoded text]]
    [[Base64 encoded html]]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eike Rathke@21:1/5 to All on Tue Jan 12 14:29:19 2021
    * cjsmall, 2021-01-12 01:29 UTC:
    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]

    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_-- --_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

    --
    OpenPGP/GnuPG encrypted mail preferred in all private communication.
    GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Use LibreOffice! https://www.libreoffice.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cjsmall@21:1/5 to Eike Rathke on Tue Jan 12 11:41:32 2021
    On Tuesday, January 12, 2021 at 6:29:20 AM UTC-8, Eike Rathke wrote:

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eike Rathke@21:1/5 to All on Tue Jan 12 21:40:18 2021
    * cjsmall, 2021-01-12 19:41 UTC:
    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?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.

    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

    --
    OpenPGP/GnuPG encrypted mail preferred in all private communication.
    GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Use LibreOffice! https://www.libreoffice.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Pearson@21:1/5 to cjsmall on Wed Jan 13 21:27:49 2021
    On Mon, 11 Jan 2021 17:29:07 -0800 (PST), cjsmall wrote:
    [snip]
    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]

    Message:

    [[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:

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

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