PDF attachment converting to Base64 plain text

[PSC]

I have the same problem here, is there any solution ?

[BruceLeeRoy]

I'm having the same issue with Zoom meeting invites from one particular sender. in EFA it shows as an attachment named partialMessage.bin
When the person cc's the invite to a Yahoo account it is received there as an attachment named invite.ics, other recipients get the actual Zoom invitation with options to add to their Outlook Calendar. Recipients getting the invite through EFA get the garbled text which seems to be the same as what's in in partialMessage.bin and invite.ics when opened with a text editor. the attachment in EFA is identical to the one that went to the yahoo account.

[shawniverson]

partialMessage.bin is normal behavior for MIME parts with a mismatched size, which is all-to-common with PDF attachments. What is not normal is this getting passed along to the client. I'm accepting samples to troubleshoot this further.

[PSC]

Excluding certain email addresses from scanning is only a partial workaround. We have an increasing number of partial messages with all kind of attachments. .ics and .pdf are most of these. Since capturing email in front of EFa is really complicated we really need a solution for this problem.

[shawniverson]

If you want me to fix this, then I need a good sample of one intercepted prior to it being processed by the system so that I can isolate what is leading to this problem. Under normal conditions a partialMessage.bin should not show up as such on a client, even though it shows up in the appliance that way from the MIME parsing.

Also I have no incoming mail triggering this condition on my relays. Without a sample this is difficult at best to resolve so it is going to take time for me to track down. So far I can't seem to reproduce the right conditions.

[shawniverson]

I did see where someone mentioned that releasing the mail from the UI leaves it intact, maybe this would be a way to capture one? Release it and get me a a raw copy with headers?

[PSC]

@shawn

We are trying to produce a repeatable email situation for you, so you can check the problems directly.
This is on EFav4, We never had such problems with EFav3. Maybe there are some new issuses with that EFav4?

Until now we can repeatable create a Zoom (https://zoom.us/) invitation for a video meeting.
When sending such an invitation via local outlook to an EFAv4 protected mail server, this email gets there but with a
partial message inside EFAv4 but delivers correct to outlook as you wrote in your post.
If you can reproduce this via Zoom, maybe this can help to investigate the situation.

There is the major question, the first time such an email arrives it delivers automatically with the partial message to the client.
Manually releasing it again to the client mail server, the message delivers correctly.
So is there any difference between this two situations?
Logically it depends on the Efa release routines, whether this attachment (partial message) is correctly delivered or not.
As you wrote partial messages are part of the game, but EFav4 has two ways to deliver it, first time wrong, second time correct?

As for samples, i can only copy the email file directly from the EFA filesystem and send it to you. WIll this help?

[PSC]

Is there any chance that this problem is related to UTF-8 codings in Outlook itself ?

[shawniverson]

Well, this gives me something to work with. I'll sign up for Zoom and run some tests. I don't have an O365 tenant, but maybe we can start here and see what may be happening. Maybe something is triggering a reconstruction of the mime parts during normal delivery and causing it to be reinserted incorrectly. Ideally only the header should be altered with scanning results and the body left intact. Even if the client doesn't care, I should see some info in the raw message itself.

[shawniverson]

@shawn
Until now we can repeatable create a Zoom (https://zoom.us/) invitation for a video meeting.
When sending such an invitation via local outlook to an EFAv4 protected mail server, this email gets there but with a
partial message inside EFAv4 but delivers correct to outlook as you wrote in your post.
If you can reproduce this via Zoom, maybe this can help to investigate the situation.

I am having trouble generating this without an Outlook client, can you generate this email and send to shawniverson@summitgrid.org ?

[shawniverson]

Well, I received the test email. It shows the partialMessage.bin as expected in the MailWatch UI (no filename defined, just a MIME type).

When I received the email, the .ics file was intact. I also released the email a second time, and compared the attachment mime part with a sha256 hash:

Code: Select all

e56de70afa6d08cdcf6ac8d00ee36ad9c2def3fbe8e724b7d94ee4377748f2a8  first
e56de70afa6d08cdcf6ac8d00ee36ad9c2def3fbe8e724b7d94ee4377748f2a8  second

The UTF-8/Base64 (including the MIME boundary) are identical in both instances. Is Zoom still exhibiting any bad behavior for you @PSC?