Jun 22

Written by:
6/22/2010 4:51 PM 

I recently ran into an interesting challenge.  A custom module was failing to send SOME emails.  By that I mean that some were being sent and some not.  After doing a little research in the email log files it was determined that the emails in question were not ever reaching the email server.  Thus the problem had to be in DNN.  Here is the scenario:

The custom module in question was calling the DotNetNuke.Services.Mail.Mail.SendMail method.  The event log shows that an Invalid email address was used.  The email address being use in the From: field was someone@somewhere.travel, and the email address being used in the To: field was someoneelse@somewhereelse.com.ni   (the name and domain have been changed to protect he innocent).   Both of these email addresses are valid. 

I seem to remember in the past that there was some kind of email address check but I could not remember what.  I was wondering if the new “.travel” extension was the issue.  Therefore, being the good community person that I am (and also because I was being lazy), I asked three people in the community if they could remember anything about email validation (again names withheld to protect the guilty).  To my surprise, no one had any remembrance of an email validation check.  Ok.. to the source code I go…

In the Library/Services/Mail/Mail.vb  file I found that the SendMail method called a shared method called IsValidEmailAddress (located in the same file). The IsValidEmailAddress method uses System.Text.RegularExpressions.Regex.Match method to verify the email against a regex pattern.  The pattern can be found in two places.  The first place is in the Library/Common/globals.vb file.  On or about line 119 is the following:

Public Const glbEmailRegEx As String = "\b[a-zA-Z0-9._%\-+']+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,4}\b"

This is used if there is not a Portal Settings with a name of “Security_EmailValidation”.  If there is such a setting, then the one in the PortalSettings table is used.  Upon investigation, I noticed that the exact same regex string was in my PortalSettings table.  If you notice the highlight in the above regex string, you will see that the extension is limited to a minimum of two characters and a maximum of 4 characters.  Ah… an easy change!  All we need to do is to change the above string to:

\b[a-zA-Z0-9._%\-+']+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,6}\b

in the PortalSettings table.  Now many people will jump to their favorite  DB editor and open the table and do the edit.  Although you can do this, I do not recommend doing direct edits to the DB unless you have no other options.  This would be an easy edit, but why take the risk when DNN has provided a UI that will allow you to make this change safely.  

To change this you will need to be logged in with a user account that has the Admin Role (or as a Host user).  Go to the Admin->User Accounts page.  On either the dropdown action menu or at the bottom of the User module, select “User Settings”.  If you scroll down you will see something like the following:

 

You can make the change to the regex right here and you are done.  Problem solved!

As more and more of these new domain extensions are being used you probably need to be aware of this and be able to address any issues that arise from these new domain names.  Maybe now would be a good time to start asking the RegEx gurus in the community if they can help us find a stricter, more comprehensive pattern for validating emails.  If you have one, let us know!!!