Setting Content-Transfer-Encoding for attachments

[NiKiZe]

Hi, This might be the wrong place to ask, if so i apologize.

I'm trying to send an attachment with Content-Type message/rfc822; name=email.eml To do this Content-Transfer-Encoding must not be base64 From rfc2046 :

No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this. Non-US-ASCII text in the headers of an encapsulated message can be specified using the mechanisms described in RFC 2047.

Example on how this attachment is created when used with classic SmtpClient:

        var messageAsAttachment = new StringBuilder();
        messageAsAttachment.
            Append("MIME-Version: 1.0\r\n").....;
        var att = Attachment.CreateAttachmentFromString(messageAsAttachment.ToString(),
            new System.Net.Mime.ContentType("message/rfc822; name=email.eml"));
        att.TransferEncoding = System.Net.Mime.TransferEncoding.SevenBit;

The resulting relevant part of sent mail is: working - standard SmtpClient

----boundary_0_d668cbe2-5f07-46bf-9206-0d04b65caa8a Content-Type: message/rfc822; name=email.eml Content-Disposition: attachment Content-Transfer-Encoding: 7bit

MIME-Version: 1.0 Date: .....

non working - postmark

----boundary_17607376_ad705c44-a38c-42e6-8d4d-b3d2aabef636 Content-Type: message/rfc822; name=email.eml Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=email.eml

TUlNRS1WZXJzaW9u......

The definition of non working in this case is that Outlook 2013 is not able to handle the contents of email.eml, while the working one works.

Is there any magic that I can apply somewhere to be able to send this correctly via Postmark? Eighter by be able to force Content-Transfer-Encoding, Or maybe this could even be forcefully modified by Postmark in the case that any Content-Type: message/rfc822 attachment is being passed thru the system?

[atheken]

Thanks for the report, this is not an issue with the .net client, but rather, with the internal processing of mail on the postmark side. I'm opening a ticket on our internal bug tracking system, and will work on getting it resolved there. Please feel free to contact Postmark support to follow up on this issue.

[NiKiZe]

Just for documentations sake it would be great if we could get an update, has this issue been resolved internally?

[mfbx9da4]

yes would also like to know - is it even possible to set Content-Transfer-Encoding: 7bit and the likes?

[NiKiZe]

As described above, but to clarify: Our workaround for this was to generate our own RFC822 message and attach that to the email encoded as base64 - a horrible waste of bytes when everything. (escentially it became: an email in an email in an email (we just wanted 2 levels but had to do 3 levels to get valid encoding)

[mfbx9da4]

Unfortunately that doesn't work for me - the clients I sending emails to require Content-Transfer-Encoding: 7bit to interpret the attachment correctly.

[NiKiZe]

the clients I sending emails to require Content-Transfer-Encoding: 7bit to interpret the attachment correctly.

And the same was true for us, and as I said, to work around that I added an extra layer of rfc822 Which meant that the "real" mail was an email as an attachment inside the email. - not user friendly in any way, but at least I was able to get the contents delverd.

Now the question is still when postmark has a real fix for this? @atheken