We are receiving emails from a Mcafee SAAS Email service user that is not readable.
Users see mime encoded message.
Any idea what the fix for this is?
Moved provisionally from Community Help to SaaS Email Security for better support.
I appologize for the delay in response to your inquiry. Are you still experiencing this issue? If yes, please contact support so we can take a look at this issue and try to come to resolution for you.
At minimum, we will need the To/From/Date/Subject information for one of the messages in question.
System Support Specialist
McAfee SaaS Email and Web Security Technical Support
System Support Specialist
SaaS Email and Web Security
McAfee.Part of Intel Security.
I actually had the same error this week and received a responce from McAfee, this should help out:
The issue is actually on the recipient side. Something on the recipient server is truncating, removing or not interpreting the boundary and multipart sections, so it looks all garbled ( I suspect something with the TNEF- Transport Neutral Encapsulation Format). Without the 'boundary' definition & the multipart specification, there is no way that the mail client can decipher the message.
This can be seen 2 ways.
1 - The same message can be sent to other client and is not garbled.
2. If you look at the encoding, it is listed as base64. If I take a portion of the encrypted message and run it through a base 64 decoder (IE- http://www.base64decode.org/) it is shown just fine.
The issue is that the recipient server is truncating, removing or not interpreting the boundary and multipart sections, so it looks all garbled ( I suspect something with the TNEF- Transport Neutral Encapsulation Format). Without the 'boundary' definition & the multipart specification, there is no way that the mail client can decipher the message.
Hope this helps!
I an having what I think is the same issue. A customer is getting the multipart/alternative raw message as an alert to log into the portal. The actual base64 content can manually be decoded correcty as described here.
We have found that the issue is with boundary tag within the automated email alert is 71 chars long and the RFC standard states it can not be longer then 70 chars. The customer started seeing the issue when they put in place a new Oracle Messaging Server that is enforcing the 70 char standard and trashing boundary so it is not decoded.
As you can see from the snippet below that the boundary within the quotes is 71 chars.
Not sure how to get this information to someone at McAfee that can look into this. Hopefully someone will read this and pass it along. Otherwise I maybe forced to change vendors for our secure emails.
This is a multi-part alternative message in MIME format.
This is a multi-part related message in MIME format.