]> Posts for November 2019 🌐:aligrant.com

Forwarding on SMTP email through BizTalk Server

Alastair Grant | Friday 22 November 2019

I have recently stumbled on some interesting behaviour on the BizTalk SMTP adapter, which I don't think is documented.

I was handling an untampered SMTP message (pass through receive location with no MIME decoding), sometimes known as a *.eml file.  These raw messages contain the headers, text, and attachments encoded with MIME.  As with other arbitrary file formats, you can handle these in Orchestrations by setting the message type to be System.Xml.XmlDocument, which BizTalk will treat as-is (even though there is no XML to be seen).

If you send this out via a SMTP Send Port, and have set the body of the message to be the body-part, you will receive an email which contains that raw SMTP text as an email with that as the content.  Not especially useful.

But here's the odd trick.  Consider this assignment on your outbound message:

msgEmailOut.Part(Microsoft.XLANGs.BaseTypes.ContentType) = "message/rfc822";

RFC 822 is an old RFC for defining early versions of the email format (and what we see over the wire in a SMTP data part).

Now instead of receiving the original email as a bunch of text in the body of a new email, the e-mail appears exactly as it did originally.  Further than that, it seems to work in a similar way to actual SMTP, as the headers are handled by the receiving mail server and a new Received: is appended to the header.

But now this is where it gets interesting.  Assume your original email was sent to bob@example.com, and your Send Port was configured to send to alice@example.com.  Your final message out of BizTalk will get delivered to both.

I found this strange, as in SMTP the target an email is delivered to is actually nothing to do with the To: field (which is why you can still get an email with a blank To: where everybody is BCC'd etc).  So I dug out my trusty Wireshark and had a look at what was going on.

What I found was the SMTP send adapter was interpreting the e-mail and sending the e-mail to all contacts in the To: field of the body (even though according to BizTalk, it's just an arbitrary blob of text).

The SMTP conversation looked something similar to this:

MAIL FROM: <sender@example.com>
250 2.1.0 Sender OK
RCPT TO: <alice@example.com>
250 2.1.5 Recipient OK
RCPT TO: <bob@example.com>
250 2.1.5 Recipient OK

In this scenario, this basically made BizTalk another SMTP hop.  In the situation where BizTalk is reading from a mailbox it is actually very frustrating as despite changing the To: address in the Send Port, the mail is sent to the original destination too - which lands up in an endless loop of BizTalk forwarding e-mails to itself.

But this could be very useful if you're wanting to craft outbound e-mails in a more dynamic fashion.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

ESXi 6.7 web UI SSL certificate algorithm

Alastair Grant | Tuesday 12 November 2019

I needed to rotate the certificates on a standalone VMware ESXi 6.7 host today, it seemed like a good opportunity to bring the certificate up-to-date a bit, so I duly created an ECC (elliptical curve) key and had the certificate signed.

I was unable to install the certificate through the UI, instead receiving an unspecific "Cannot change the host configuration", and an instruction to read an unspecific log file (none of them seemed to log anything related).  But it seems like a common enough problem, and simply something that doesn't work very well in the UI.

Instead you can update the individual parts directly via SSH:

/etc/vmware/ssl/rui.key - contains an unencrypted private key in Base64 PEM format
/etc/vmware/ssl/rui.crt - contains a public certificate in Base64 PEM format

You can then restart the host, or just the management agents.  And oops, everything is dead.

Something seemed to object to the new certificate and my copy in the ssl directory vanished over a reboot, so no rollback available.  You can though get yourself out of trouble by generating new self-signed certificates via this command:

/sbin/generate-certificates

This gets the Web UI back up and running.  It turns out, that ESXi does not support ECC keys, despite it being fairly standard for a number of years.  Instead you have to fall back to slow RSA keys.  I created a new key and new signed certificate and installed it in the same way via SSH (as even with the correct format, the UI doesn't work), and everything was fine - and no more security warnings.

I see so many VMware setups without valid certificates in place, and so many "sysadmins" blindly click past the browser warnings.  This bad behaviour makes a MITM attack against your management hosts easy as admins who ignore TLS warnings won't spot that the certificate has changed to that of one belong to a malicious actor.  Security 101 folks.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

Entries for: November 2019

Previous Next