XML Serialization contents of string email address


(Matt Ritchie) #1

Details: NSB 4.7.0
Significant Part of config relating to serialisation.
Configure.Serialization.Xml();

We have a single email service per environment which takes a simple command and connects to our Exchange API to send emails.
We have a new service attempting to send emails to addresses with contain “&”

We’ve written an integration test to show the behaviour failing.

public void Should_send_an_email()
{
	var sendAnEmail = new SendAnEmail();
	sendAnEmail.ToAddress = "***@domain.org.au";
	sendAnEmail.FromAddress = "***@domain.org.au";
	sendAnEmail.CCAddress = "HC&DWestern@domain.org.au; HC&D-ClientBusinessCentre@domain.org.au ";
	sendAnEmail.Body = "<html><body>TestEmail</body></html>";
	sendAnEmail.Subject = "UnitTestEmail";
	sendAnEmail.IsHtmlBody = true;
	_emailSender.SendEmail(sendAnEmail);
}

This is the output inside the XML Message inside the queue before our email service has read the message.

<CCAddress>HC&amp;DWestern@domain.org.au;HC&amp;D-ClientBusinessCentre@domain.org.au;</CCAddress>

Once read in our code it’s taking that value and attempting to send it to our Exchange API. Which fails due to the ; after amp being the syntax for separating email address.

We are seeing different behaviour in different environments, ie different app server VM’s, and in some cases the XML serialiation is working and sending via Exchange just fine.

As far as we can tell, the XML Serializer is taking over for us, but not putting it back to what was inserted.

Any hints as to how we can escape the text appropriately, or influence the serialiser?


(Tim Bussmann) #2

Hey @Matt_Ritchie

Our XML serializer does indeed escape special characters using HTML encoding. This encoding should be properly reversed by the deserialization logic. Just to verify that I understand your usage correctly: You will deserialize the message via NServiceBus and then pass that value to the exchange API? How do you pass those values to the Exchange API? Do you have to serialize the data for the Exchange API again?

We are seeing different behaviour in different environments, ie different app server VM’s, and in some cases the XML serialiation is working and sending via Exchange just fine.

I’d be interested in reproducing this issue. Can you give us some detail about the machine configuration which fails to deserialize the value correctly?


(Matt Ritchie) #3

Hi Tim,

We were expecting to see this reversed via the deserialization logic occur
without any issues as well, our first assumption was that we were
retrieving it incorrectly out of our settings database, as it’s a different
email per department. We traced it from our code into the input queue, then
into the email service, which then read the string back in as it was in the
message

We do nothing special to the characters to get into the exchange api from
the nsb command. We take the string from the message, split it via ‘;’ then
add to the to: cc: and from: fields of the email message object from
ExchangeWebServices. No serialisation from us before or after. The email
service has been running for 8 years in production without issues, but i’m
not sure we’ve ever sent it this email address before.

Our local machines are windows 10, app servers to which we deploy are
windows server 2012 R2. Both are having issues. AppServers Specs. VM’s
running on VMWare, Processor is a Xeon CPU E5-2650 @ 2.6Ghz, 18GB RAM

I’ve just checked the config of the email service, it uses the exact same
startup config as the sending service. We have an internal nuget package
containing all our bus config startup statements and it’s the exact same.

All on .net 4, all windows 10 and app servers are patched up to latest as
of about a month ago.

Cheers,
Matt


(Matt Ritchie) #4

Thanks Tim,
I’ve worked it out, nothing to do with deserialisation. I reproduced and
discovered that our transformation settings between the environments was
inputting and incorrect email address as the From: field on the email, thus
the different results in each environment.

The string had an ampersand but the issues was more to do with that account
not having a Mailbox and being able to send emails.

Cheers,
Matt


(Tim Bussmann) #5

Hey @Matt_Ritchie

Good to hear you were able to identify and solve the issue! Thanks for letting us know :+1: