How to suppress email validation when using SmtpClient and MailMessage

Question

When sending out emails using the SmtpClient and a MailMessage (.net 3.5) the "To" email address(es) get validated prior to sending. I've got a big stack of email addresses which have a dot (.) before the at-sign, causing a FormatException when you attempt to send the message using the SmtpClient. This is actually a good thing, because by specification a dot before the at-sign is invalid. Unfortunately, those emails exist in the real world and they get delivered, if you send them out using your preferred email client.

My question is, can email validation through the SmtpClient/MailMessage be suppressed?

Answer 1

Edit: Tried the sample code in VB2005 and I also got the exception. The code below works fine in VB2010 Express though so seems to be a bug that's now been fixed. The MSDN quote is from the 4.0 documenation, that snippet is not in the earlier versions of the MSDN page.

I can't try it right now but exactly how are your email addresses formatted? The documentation for the MailAddress class states that it supports Consecutive and trailing dots in user names. For example, user...name..@host. (quote copied from here).

Edit: Added sample.

Try
    Dim smtpClient As New SmtpClient()
    smtpClient.Host = "mailserver"
    Dim fromAddress As New MailAddress("[email protected]")
    Dim toAddresses As New MailAddress("[email protected]")
    Using message As New MailMessage()
         message.From = fromAddress
         message.To.Add(toAddresses)

         message.IsBodyHtml = False
         message.Subject = "test"
         smtpClient.Send(message)
    End Using
    TextBox1.Text = "OK"
Catch ex As SmtpException
    TextBox1.Text = ex.ToString()
End Try

Answer 2

This can be error after tring to send the e-mail.

Can you provide some CallStack so we can view where exactly exception is thrown

---

Update: According to the disassemble code from reflector, this problem can be sold only by upgrading to the VS2010 and .NET 4.0

Lower versions of System.Net assembly have no way to solve this problem