Chapter 5. Authentication & Security
5.1 SMTP Authentication
5.2 AspEmail's Authentication Support
5.3 Secure Mail Support
5.4 Transport Layer Security (TLS) Support
5.5 DKIM Support
SMTP servers are often configured to require an email client to provide
a username and password when sending a message. This is done to protect
the SMTP server from unauthorized use by external users,
and to prevent spam.
An attempt to send email via a secured SMTP server may result in run-time errors such as
550 Relaying Denied
The SMTP protocol provides several authentication methods through which a mail
client submits its security credentials to the server during an SMTP session.
SMTP servers usually support at least one authentication method, but most support
The most common SMTP authentication methods are as follows:
This is the simplest authentication method where the username and password are sent
to the SMTP server in clear text (that is, unencrypted) although the values
are Base64-encoded. Authentication parameters can therefore be intercepted.
The server sends a random string
to the client. Both the client and the server calculate an MD5 digest of
the concatenation of the random string and the password; the client then
sends the server the result of its calculation. The server compares the
This method is more secure than AUTH=LOGIN because the actual password never gets
sent to the server.
This is Microsoft's proprietary authentication protocol also known as "Challenge/Response".
It is also secure in the sense that the password never gets transmitted over the network.
AspEmail provides two properties, Username and Password
through which user credentials are specified.
Mail.Username = "Administrator"
Mail.Password = "He11o@World!"
When used in the standard mode (message queuing is not used), AspEmail supports the AUTH=LOGIN
method only. When sending queued mail, AspEmail, in conjunction with
EmailAgent, supports all three protocols described above. When attempting
to negotiate an authentication protocol with the SMTP server, AspEmail
tries the authentication methods in the following order: CRAM-MD5, NTLM, AUTH=LOGIN.
When used in conjunction with Persits Software AspEncrypt,
AspEmail is capable of sending signed and/or encrypted messages in the
industry-standard S/MIME format.
When sending an encrypted (enveloped) message, the AspEmail/AspEncrypt tandem
takes the recipient's digital certificate and encrypts the message with its public key.
Only the owner of the certificate can decrypt such a message since
no one else has the corresponding private key.
When sending a digitally signed message, the sender certificate's private key
is used to sign the message.
AspEmail/AspEncrypt are also capable of sending messages that are first signed and then encrypted.
AspEmail is the only ASP component on the market that is
officially certified to be S/MIME-enabled by RSA Security,
the inventor of public-key cryptography and S/MIME,
and was listed on RSA's web site among other S/MIME-enabled software products
(the list was recently removed from the RSA web site.)
To learn how to send secure mail with AspEmail/AspEncrypt,
read the Secure Mail chapter on the AspEncrypt.com web site.
Here is another useful article
by Peter Persits on implementing a secure mail application at 15seconds.com.
5.4.1 TLS (Ports 25 and 587)
As of Version 5.1, AspEmail supports the Transport Layer Security (TLS) protocol.
This secure protocol encrypts all traffic between the email-sending client application
and SMTP server, and not just the passwords. The security of the protocol is based
on public-key cryptography.
Some SMTP servers require the email sender to use TLS. An example
of such a server is Google's popular free smtp.gmail.com server.
An attempt to use this SMTP server without TLS results in the error message
530 5.7.0 Must issue a STARTTLS command first.
To enable AspEmail's TLS support, you must set the TLS property to True, as follows:
Mail.Host = "smtp.gmail.com"
Mail.Username = "MyGMailAccount"
Mail.Password = "He11o@World!"
Mail.TLS = True
Some SMTP servers requiring TLS run on port 587 as opposed to the default SMTP port 25.
If that is the case, the port number needs to be specified as well:
Mail.TLS = True
Mail.Port = 587
5.4.2 SSL (Port 465)
When the Mail.TLS property is set to True as described above,
AspEmail begins an SMTP session via an unsecured channel. It receives an SMTP server
greeting, issues the EHLO command followed by the STARTTLS
command, and then initiates a secure key exchange procedure known as a "handshake". Once the handshake is completed,
all further communications between AspEmail and the SMTP server are encrypted.
Some SMTP servers support a slightly different secure process often referred to as SSL (Secure Socket Layer).
Under SSL, the client initiates the handshake procedure immediately after connecting to the SMTP server (usually on port 465), and every single SMTP communication
including the greeting and EHLO command is transmitted via a secure channel from the start. Under SSL, the underlying secure protocol is exactly the same as under TLS,
it just kicks in at the very beginning of the SMTP session instead of in the middle of it.
As of Version 5.4, AspEmail supports the SSL protocol. To enable it, the Mail.SSL property must be set to True, and Mail.Port to 465, as follows:
Mail.SSL = True
Mail.Port = 465
Note that TLS/SSL is currently only supported by AspEmail itself but not EmailAgent.
However, it is supported by EmailAgent.NET.
5.4.3 TLS 1.2 Support
Version 1.0 of the Transport Layer Security protocol (TLS 1.0)
relies heavily on the MD5 hash algorithm, which has been cracked and is currently considered insecure.
It contains other vulnerabilities as well. TLS 1.0 will therefore soon be deprecated.
As of AspEmail 5.5, whenever the Mail.TLS or Mail.SSL property is set to True,
AspEmail by default uses TLS 1.2, a more secure protocol which is based on SHA256 and 128-bit and 256-bit AES.
To force AspEmail 5.5+ to use TLS 1.0, the new property Mail.TLSVersion must be set to "1.0", as follows:
Mail.TLS = True
Mail.TLSVersion = "1.0"
The TLSVersion property currently supports two string values: "1.0" and "1.2".
5.5.1 What is DKIM?
DomainKeys Identified Mail, or DKIM, is a method by which
the sender of email digitally signs the message to prove it really
came from the domain that is claims it came from.
The signature includes some or all message headers including, most notably,
the From: header which is often forged by spammers. The message body
is also included in the signature to prove it has not been altered.
The DKIM signature is included in the message as a regular header, for example:
Subject: Testing DKIM
Date: Thu, 26 Apr 2012 14:19:01 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;
The message recipient verifies the signature by obtaining the signer's public key
from the DNS records of the domain the message claims it came from. Unlike the S/MIME standard
mentioned above, DKIM does not use certificates but "raw" public keys for message verification.
One or multiple keys can be associated with a particular domain.
Each key is assigned a unique name, or selector. In the example above, the sender domain is
persits.com and selector is nyc. The public key to verify the signature
has to be put in the DNS record of the type TXT for the domain nyc._domainkey.persits.com.
For more information about DKIM, see www.dkim.org.
5.5.2 Getting Ready to Send DKIM-Enabled Messages
Bofore you can start sending messages equipped with DKIM signatures using AspEmail or AspEmail.NET, the following
steps must be taken:
- Obtain a personal certificate.
Certificates are a convenient mechanism for obtaining, storing and distributing
public/private keys needed for DKIM signing and verification, and our products' API relies on them.
Since DKIM does not use certificates themselves, it is not important
where you obtain your certificate. We recommend using our live demo
specifically designed to acquire DKIM-friendly certificates instantly.
Please point your Internet Explorer to the following link and follow the simple instructions:
If you need multiple keys, obtain a separate certificate for each key.
Export the certificates from IE to files both with and without their private keys
(file extension .pfx and .cer, respectively.)
- Create DNS TXT records for each key.
For example, for the domain mycompany.com and selector hq,
you must create a DNS record of the type TXT for the domain
The value for this TXT record must contain the base64-encoded public key of your certificate in the form
You can obtain the public key for your certificate programmatically using AspEncrypt's
property (AspEncrypt 2.7+ is required,) but for your convenience we have set up an online application which enables you to upload your .cer
file to our server and obtain the value for your TXT record instantly:
Verify the validity of your DNS record via the following online tool (warning: the link below is not a Persits Software page):
5.5.3 AspEmail's DKIM Support
Once the DKIM infrastructure has been set up, you are ready to send email equipped with DKIM
signatures. As of Version 5.3, AspEmail offers the SendCertified method
which expects 4 required and 1 optional arguments: the signer certificate, domain, selector,
option flags, and optionally the message queue path.
- The signer certificate argument is an instance of AspEncrypt's CryptoCert object. It can be obtained
either from a .pfx file or directly from a certificate store. For more information
about using certificates for signing purposes, see Section 5.4
of the AspEncrypt user manual.
- The domain and selector arguments are two strings specifying the domain and selector
(such as "mycompany.com" and "hq" in the example above.) The message recipient uses this information
to obtain the public key for signature verification from the domain's DNS records. Note that the domain must match
the domain of the email address specified via the Mail.From property.
- The option flags argument is a collection of flags and should normally be 0. Currently, only two flags are defined.
Bit 1, if set, prevents the Date header from being included in the signature, bit 2,
if set, prevents the Message-ID header from being included in the signature.
- The last optional argument is only used when message queing is enabled and has the same purpose as the
optional Path argument to the Send method.
The integrity of a DKIM signature relies on the message headers and body being in a standard
(or "canonicalized") form. To ensure the body is properly formatted, you must set
the property ContentTransferEncoding
to "Quoted-Printable" before calling SendCertified. If necessary, also use the method EncodeHeader
for the headers such as Subject and others.
The following code sample sends a DKIM-signed message:
' Obtain signer certificate from pfx file|
Set CM = Server.CreateObject("Persits.CryptoManager")
CM.LogonUser "domain", "username", "pwd" ' Needed to avoid error
Set Store = CM.OpenStoreFromPFX("c:\path\cert.pfx", "password")
Set Cert = Store.Certificates(1)
' change to address of your own SMTP server
strHost = "smtp.myisp.net"
Set Mail = Server.CreateObject("Persits.MailSender")
Mail.Host = strHost
Mail.From = "firstname.lastname@example.org"
Mail.Subject = "Thank-you for your business"
Mail.Body = "Message body"
Mail.ContentTransferEncoding = "Quoted-Printable" ' Required
' Domain must match Mail.From address
Mail.SendCertified Cert, "mycompany.com", "hq", 0