I've got a webhook which is parsing emails sent by SendGrid's Inbound Parse, and if any error occurs with processing the email, I want to send the original email as an EML attachment to a notification email address.

I've been using Busboy to parse the multipart/form-data received by the webhook and I receive the full plain cleartext of the email contents itself. Everything is fine there.

When I go to send the email using @sendgrid/mail and set the original email as an EML attachment file, this is where I get issues.

I've tried a variety of content encodings and mimetypes, but haven't found one that works yet as a EML file. I've tried text/plain, message/rfc822 and application/octet-stream with plain text (which results in error from SendGrid API), and base64 encoded text.

In fact, it gets weirder. When I send the email attachment as text/plain with filename ending in .txt, everything seems to be good. When I download the attachment and rename to .eml then it views perfectly in my Mail app.

However, when I send the email attachment as text/plain, message/rfc822 or application/octet-stream with filename ending in .eml, this is where I get inconsistencies. In the email I sent I can see that the filename now ends with .eml.eml and opening the file in my Mail app shows me base64 encoded text (decoding the text gives me the original email contents that I had to encode in order to allow the endpoint to send as an attachment). Viewing the file contents in a text editor looks like this:

Content-Type: text/plain
MIME-Version: 1.0

VGhpcyBpcyB3aGVyZSB0aGUgYmFzZTY0IGVuY29kZWQgZW1haWwgdGV4dCBnb2Vz

My current conclusion is that the SendGrid /v3/mail/send API endpoint is treating attachments with .eml extension in the filename differently and encapsulating the base64-encoded contents within another .eml wrapper. It doesn't seem possible to set an attachment's content to a plain text string as I get a 400 Bad Request from the endpoint if its not base64 encoded.

I haven't been able to find any official documentation about this particular behaviour on this endpoint. The closest I got was this GitHub issue (dated 2018), but it doesn't seem to solve my issue.