When it comes to validating e-mail addresses my philosophy is an all or nothing
one. You either validate the e-mail address by way of sending an e-mail to
it to check that it is active, or you just don't bother at all. I have seen
scripts that let you check there is an @ sign and at least one period in
the domain name, etc., etc. Or suggestions of stripping the domain name and
doing a whois on it to ensure it is valid. Why bother spending time and effort
implementing methods that just don't do the job completely?
I can still enter
And it will pass a syntax checking script, and a domain check on server.com
but it still isn't a valid e-mail address. If, as a user, I want you to have
my e-mail address I will give it to you. If I don't then I will make one up
and give you that instead.
If you have a service where you really need to guarantee an e-mail address
is genuine, then the best way to do that is to send a mail to it that contains
further activation instructions. So our solution will have a table that holds
the user's details, along with their e-mail address, and we will store an activation
code as well. An e-mail will be sent to the address containing further instructions
and links that allow the recipient to automatically activate their account.
By way of a simple example I will create a table called User that will contain
the details of the users of my system. The SQL naming convention in this example
is far from ideal, but I wanted to keep things simple. In the real world I
would not use so many reserved keywords for table and field names. Throughout
this example I am using SQL Server, but I have added the relevant details for
using Access at the end.
We need a table to store the name and e-mail address of our users, along with
an activation code and a flag to say if the account is active yet. The table
will look like this.
The script to generate this table is below;
CREATE TABLE [User] (
[ID] [int] IDENTITY (1, 1) NOT NULL ,
[Name] [varchar] (50) NOT NULL ,
[Email] [varchar] (255) NOT NULL ,
[Code] [char] (10) NULL ,
[Active] [bit] NOT NULL
When we insert a new user into this table we want to store their details along
with an activation code, and we will initially set their Active flag to false.
I'll discuss the activation code when we come to the ASP, but for now here
is the stored procedure (SP) we will use to insert the new row.
-- CreateUser SP --
CREATE PROCEDURE CreateUser
You can see that the INSERT sets the Active flag to "0" meaning
this account is not yet active.
When the user activates the e-mail account we need a SP to carry out that
function. This is a simple matter of updating the User table to set the Active
flag to true for the record with that activation code.
-- ActivateEmail SP --
CREATE PROCEDURE ActivateEmail
SET Active = -1,
Code = null
WHERE Code = @Code
Finally, our system has a handy page that shows us the contents of the user
table so we need an SP to retrieve the contents of the User table.
-- ListUsers SP --
CREATE PROCEDURE ListUsers AS
That is all the database stuff we need, now we can look at the ASP code that
will tie it all together.
The solution has three pages in total. (Download these pages here: addressing.zip)
Default.asp - This page has a form that posts to itself that allows people
to create an account for themselves. The code will generate an activation code
and store the details in the database and constructs a sample e-mail to send
to the user. This demo only writes the e-mail to the screen, however.
In your solution you will need to plug in the code that sends an e-mail
via the particular component you are using.
Activate.asp - this page contains code to activate the account. If the code
is sent on the querystring then everything is done transparently and the account
is activated and the user redirected to a confirmation page. If the user navigates
to this page directly then they are given a form (also
self-posting) with which they can enter their activation code manually.
List.asp - this is a page that shows us the contents of the
This is a handy debug tool only.
The code for each page is fully commented so you can follow the workings from
the download source.
This page has a form that posts to itself so if the page is viewed directly
then we only want to show the form. If the page is being viewed because the
form has been submitted then we want to run the code that creates the user.
We do this by having a hidden field in the form called "Add" and
we check to see if that form item has a value, and if it does we know
the form has been submitted.
if Request.Form("Add") <> "" then
Next we want to generate the activation code. This is a string of 10 random
ASCII characters in the range of a-z. To pick a random character we need a
random number that lies between the ASCII values of a and z. We get this using
the following code
CInt(Rnd * (iMax - iMin)) + iMin
Where iMin is the ASCII value of "a" and iMax is the ASCII value
of "z". We turn this into a character by using the Chr function
and just append ten of them together by iterating through a loop.
If you wanted to be super-smart you could now do a look-up to make sure that
the code does not already exist in the User table. The chances are slim, but
there is still a chance that you pick the same 10 characters more than once.
To help eliminate duplication we delete the activation codes from the database
when the accounts are activated.
Now that we have our activation code it is a simple matter of calling the
CreateUser SP and passing the relevant parameters.
We also need the e-mail to be sent out but I have left the exact working of
how you do that down to you as the code for all e-mail components will differ.
What the code does do is build the body of the e-mail that you will want to
send out which includes links they can click on to automatically activate their
There are some things that are hard-coded in the code that you will need to
change. One is the connection string to the database, and the other is the
URL to your Activate.asp page. It is indicated in the comments where you need
to alter these things. The URL needed to activate the account is activate.asp?Code=xyz
where xyz is your activation code.
As this page can also post to itself we check the presence of the QueryString
to see if the Code parameter has been supplied. If it has then we call the
ActivateEmail SP, which activates the account, then redirect to another page.
In this example we redirect to List.asp which shows the contents of the User
table, but in reality you would redirect to a page thanking them for activating
their account etc.
If you are using this type of solution to control logins for a website then
you obviously need to check that the account has been activated (by checking
the Active flag) when they supply their username and password.
Modifications for Access
Here are the details you need to get the solution working with Access. The
ASP code remains the same, you just need to ensure your connection string points
to your Access database.
-- Table definition --
ID - Autonumber
Name - Text field, 50 in length
Email - Text field, 255 in length
Code - Text field, 10 in length
Active - Yes/No field
-- CreateUser Query --
PARAMETERS Name Text ( 50 ), Email Text ( 255 ), Code Text ( 10 ); INSERT
INTO [User] ( Name, Email, Code, Active ) SELECT Name AS Expr1, Email AS Expr2,
Code AS Expr3, 0 AS Expr4;
-- ActivateEmail Query --
PARAMETERS Code Text ( 10 );
UPDATE [User] SET [User].Active = -1, [User].Code = Null WHERE (((User.Code)=[Code]));
-- ListUsers Query --
SELECT [ID], [Name], Email, Code, Active FROM [User];