Fetch Email - Excel Attachments Coming Through As 'Smime'

I have used my personal email account (which has a ‘digital signature’ certificate, per our company’s policy) to send a simple email with an Excel file attachment to a shared email account setup to be an EasyMorph connector. I would like to fetch this Excel file attachment and place it in a specified folder as part of a larger automated process.

The issue is that when using the action ‘Fetch Email’ to grab the attached Excel file, it does not place the attachment in the specified folder as an Excel file, but as a Smime (with type: ‘P7M File’) which breaks the process.

From some quick googling, it looks like this is due to the Sender’s email signature. Microsoft Article

This doesn’t happen with ALL attachments, as we have some examples of third-parties sending emails and the EM connector is able to grab the attachments as expected. Of course, I don’t have visibility into how those senders have their accounts set up. Any guidance here would be appreciated. Thanks!

Hi Jacqueline,

Which email service and EasyMorph connector are you using? Are they the same or similar for both sending and retrieving workflows?

Hi Andrew,

Thanks for the reply. The connector type for the receiving email is Microsoft Exchange Online, the authentication is OAuth. To be clear, I am sending the email from my personal account manually via the Outlook desktop app, and trying to use EasyMorph to fetch the email & attachment automatically by setting up a connector for the receiving email. It works normally (downloads the Excel file attachment correctly) when I unclick the digital signature button in the Options menu in Outlook. When I send the email with the digital signature, that’s when it fails and the attachment is saved in the output folder as ‘SMIME’. Per our company policy, we should be sending all emails with our digital signature. I am curious if you have run into this issue before or know of a workaround.

Screenshot 2023-06-12 101919

@andrew.rybka @jacquelineharris

I remember sometimes when you send an email with the digital cert that a message pops up asking if you want to allow access to the certificate? I believe it is the first time to a recipient if memory serves me correctly. Could it be related to that?

Update: I am having our team check the following setting on the sending account to make sure it is set:

Send digitally signed messages as clear text

Select this option if you want the contents of the message to be readable for all recipients. This includes recipients without an S/MIME mail application. A recipient without an S/MIME mail application can read a clear text message but can’t verify the digital signature.

1 Like

@andrew.rybka @jacquelineharris

I made a quick test and fetched an email attachment with the “send in clear text” option enabled. Same result. It fetches the digital signature file.

Thanks.

@andrew.rybka If you are using the EWS API, which I think the Exchange Online connector does, I have read that it doesn’t support SMIME.

image

@jcaseyadams It may be related to that.

@jacquelineharris Yes, the Exchange Online connector uses EWS API internally.

But it’s possible that there is a workaround.

Can you please send two emails with random attachments to the following address: test.user@easymorph.onmicrosoft.com ?

Please send the first email with the “send in clear text” option enabled and the second one with that option disabled.

@andrew.rybka I have sent the two emails you’ve requested. Please let me know if you need anything else from me at this time. Thanks!

Hi Jacqueline,

Thank you for the files. I haven’t been able to find a simple way to make the “Fetch email” action to support such attachments. But it seems that smime.p7m files, fetched from both messages,
contains XLSX files encoded to base64.

I created a simple EasyMorph project that can be used to decode separate files from attached smime.p7m files: Decode attachment.morph (4.6 KB)

You have to specify a path to a smime.p7m file, the name of the attached file, and a path where the decoded attachment should be stored.