Before you get your hopes up, this is not a How To of sending messages via email using BizTalk, instead this is advice not to do it. Why is that you ask? See my reasoning below, feel free to use this to tell your boss/solution architect/client etc. as to why they shouldn’t implement a solution that sends business documents via email, except when they go to a person, rather than a system.
There is no interface contract
Unlike web services there is no WSLD or Swagger to define the interface, so how it is implemented at both ends is usually very loose. I’ve seen multiple solutions in Production that relied on messages received by email break when the sender decided to change how they were sending the payloads without notice.
It is insecure
It is ridiculously easy to spoof a From address or use a fake address that looks similar to the real one, and unless the receiver uses SPF, DKIM or DMARC the receiving mail server and system will not notice.
By default emails are sent un-encrypted, this could leave you open to a man in the middle attack where payloads are altered. So you have to encrypt or de-crypt in the MIME pipeline, and exchange certificates.
By default emails are digitally unsigned, so receiver cannot verify with 100% accuracy that the payload was sent from your system unless you go to the trouble of signing the payload and the receiving system verifies.
The authentication options to send emails are Basic, which sends credentials in the clear across your network, NTLM authentication (which is also vulnerable to chosen plaintext), or your mail server needs to be set not to authenticate client apps that are sending emails. The standard BizTalk SMTP adapter does not support SSL/TLS connections either. So you would have to use something like Stunnel as per an answer in the thread BizTalk 2016 SMTP/POP3 with TLS 1.2
For receiving emails your choices are Basic, Digest and SPA, but at least there is a Use SSL option available so your credentials aren’t sent in the clear. Note Use SSL probably also enables TLS, as the SSL protocols are deprecated and disabled in most systems.
It is unreliable
There is no guaranteed delivery with emails. Email servers can occasionally start treating legitimate emails as SPAM, and then the emails and payloads are never received by the receiving system.
There us usually no acknowledgement mechanism that the email has been received* and processed. So again if you want that then the receiving system has to send an acknowledgement back somehow.
* as this mechanism was heavily abused by Spammers and so disabled on most mail servers.
It is complex to implement
There are also sorts of pitfalls when you try to send emails with documents attached, in getting it sent in the first place (security), how it is sent (body or attachment), getting the attachment names correct, and even the encoding of the attachments can cause issues, at one point there were three different standards for attachments, and usually the receiving system would only support one or maybe two of those.
For example, some Stackoverflow question over the years.
- Add PDF attachment to BizTalk email service
- Biztalk Server 2006 HTML Email with inline images
- How/Can I Send an Email in BizTalk with an Excel attachment?
- Attachment name in Outlook looks wrong (encoding issue?)
- BizTalk – Setting email contentType causes error: There is an error in XML document (1, 1)
- Body part is sent as attachment in biztalk dynamic SMTP Send port
- Send HTML email in BizTalk with multiple pdf attachments with SMTP adapter
- Why is the email atachment i sent by BizTalk “body.csv” in OUTLOOK 2016?
BizTalk Framework Assembler Pipeline Component
Tom Canter pointed the BizTalk Framework Assembler Pipeline Component out to me in response to this article, which overcomes some of the above.
BizTalk musings 
One thought on “BizTalk – Sending messages via email”