5

As many people may already be aware, correctly validating email addresses can be somewhat of a nightmare. You can search all day long for a C# regex that matches the current RFC standards, and you'll find different regex expressions that give different results.

If you look at http://en.wikipedia.org/wiki/Email_address#Local_part, you'll see that a period at the beginning or end of the local part is not allowed. Two consecutive periods are also not allowed. However, the following NUnit test proves that System.Net.MailMessage allows you to instantiate a MailMessage object for some invalid email address formats.

[Test]
[TestCase(@"foobar@exampleserver")] //technically valid from the wiki article
[TestCase(@"jsmith@[192.168.2.1]")] //technically valid from the wiki article
[TestCase(@"[email protected]")] //vanilla email address
[TestCase(@"[email protected]")] //also standard
[TestCase(@"[email protected]")] //long with lots of periods
[TestCase(@"[email protected]")] //disposable with the + symbol
[TestCase(@"[email protected]")] //period and dash in local part
[TestCase(@"[email protected]")] //lots of hyphens
[TestCase(@"!#$%&'*+-/=?^_`{|}[email protected]")] //all these symbols are allowed in local part
[TestCase(@"ër_%لdev@gكňil.com")] //characters outside the ascii range are permitted
[TestCase(@"""abcdefghixyz""@example.com")] //technically valid
//[TestCase(@"abc.""defghi""[email protected]")] //technically valid, but .NET throws exception
public void CanCreateMailMessageObjectTest(string emailAddress)
{
     var mailMessage = new System.Net.Mail.MailMessage("[email protected]", emailAddress);  
}

All of the above test cases pass except the last one.

[Test]
[TestCase(@"[email protected]")] //leading period
[TestCase(@"[email protected]")] //period at end of local part <---FAIL
[TestCase(@"[email protected]")] //double period in local part <---FAIL
[TestCase(@"foobar@example!#$%^&*()=server.com")] //special characters in domain part
[TestCase(@"Abc.example.com")] //No @ separating local and domain part
[TestCase(@"A@b@[email protected]")] //more than one @ symbol
[TestCase(@"just""not""[email protected]")] //quoted strings must be dot separated
[TestCase(@"a""b(c)d,e:f;g<h>i[j\k][email protected]")] //special symbols "(),:;<>@[\] not inside quotes
[TestCase(@"[[email protected]")] //leading special symbol in local part
[TestCase(@"this is""not\[email protected]")] //spaces not in quotes
[TestCase(@"this\ still\""not\\[email protected]")] //backslashes not in quotes
[ExpectedException(typeof (System.FormatException))]
public void CannotCreateMailMessageObjectTest(string emailAddress)
{
    var mailMessage = new System.Net.Mail.MailMessage("[email protected]", emailAddress);
}

Why on earth do [email protected] and [email protected] fail to throw a System.FormatException? Who is wrong here, Microsoft or Wikipedia? Are there any email addresses that are grandfathered in to allow trailing period or double period? Should my validation allow them? I have the proper exception handling in place to allow my email delivery service to carry on about its day if an exception occurs, but I'd like to throw out email addresses that are either invalid or guaranteed to throw an exception.

jreancsu
  • 421
  • 5
  • 13

2 Answers2

3

There's no explanation of why, but MSDN's docs on System.Net.Mail.MailAddress calls out that this address format is supported:

The MailAddress class supports the following mail address formats:

...

  • Consecutive and trailing dots in user names. For example, user...name..@host.

So it's not a bug in the MailAddress class - that form is explicitly supported. But I don't know what the reason is for supporting them. I'd assume that maybe some systems actually accept them, and MS feels the need to support that scenario.

On the other hand, while I can understand the need to provide some validation of email addresses, my personal opinion is that there's little need to be super strict in the validation. The system needs to handle bad, but syntactically valid, addresses anyway. On the other other hand, it seems like a doubled period or period at the end of the local-part might be a common typo, so I can understand why you might want them to fail validation.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • "might be a common typo" --> Exactly. I fail them for that reason. I mostly just want to fail addresses that are a) obviously invalid, or b) I know won't get delivered because MailAddress/MailMessage throws an exception (which I handle, but still...). – jreancsu Oct 07 '14 at 20:42
0

Well, since the RFCs define the Standard, it would be Microsoft's implementation that's incorrect.

If you want to do better validation, try the validator I posted in this answer to the question C# Email Address validation.

It should properly (and strictly) validate pretty much any "normal" email address of the format local-part@domain that you might encounter, though it won't deal with the new non-ASCII style stuff that's allowed. I don't guarantee that a little bit rot hasn't set in since its a few years old and the email RFCs have been updated since I wrote it.

The local-part must be unquoted: it doesn't support quoted local-parts, or quoted labels.

As far as the domain portion goes, my validator doesn't support IPv4 or IPv6 literals (though it wouldn't be difficult to add that).

If you want to allow any/all RFC-compliant addresses, it gets much more difficult.

Community
  • 1
  • 1
Nicholas Carey
  • 71,308
  • 16
  • 93
  • 135
  • Thanks for posting your 3 1/2 year old solution, but that's not really what I was looking for. I can acquire regex from FluentValidation and Microsoft or write my own, but the problem is that they're all different. This post doesn't ask for a regex, but questions why MailMessage doesn't raise FormatException. – jreancsu Sep 19 '14 at 17:58