Our customer has a e-mail campaing system that sends out around 30.000 opt-in emails to its customers every now and then. Nothing spectacular but it handles keyword substitution, independent operation for long running tasks, some pretty wild cyrillic texts.

Recently though sending newsletters to customers with non ASCII characters in their names stopped working, something which did work before, the only recent changes were some added tracing instructions and exception handling.

Here’s why!

  using System.Net.Mail;
  using System.Reflection;
  using NUnit.Framework;
  
  namespace Tests {
    [TestFixture]
    public class TestMailMessage {
      [Test]
      public void TestSending() {
        string email = "test@example.com";
        string name = "Börje Bengtson";
        MailAddress a = new MailAddress(email,name);
        MailAddress b = new MailAddress(email,name);
        b.ToString();
        BindingFlags flags = BindingFlags.Instance |
                             BindingFlags.NonPublic |
                             BindingFlags.InvokeMethod;
        string encodedStringA = typeof(MailAddress)
          .InvokeMember("ToEncodedString",flags,null,a,null);
        string encodedStringB = typeof(MailAddress)
          .InvokeMember("ToEncodedString",flags,null,b,null);
        /** BOOM! **/
        Assert.AreEqual(encodedStringA, encodedStringB);
      }
    }
  }

Calling the ToString() method before ToEncodedString() (which is called when sending the message) will pollute the MailAddress internal state with an unencoded version of the address that is returned as a cached version on subsequent calls to ToEncodedString().

Turns out some of the added tracing code printed out the address of the receiver it was processing at the moment, triggering the bug in the framework.

Now, if I could only find somewhere to report this…