Posted by & filed under General.

I’ve been asked a few questions on email addresses and their limitations or recommended practices as a server administrator. I will outline a small bit of information in regards to valid email addresses, server types and spam evasion.

The Internet Engineering Task Force RFC (Request for Comment) 2821 defines the local part of an SMTP email address a maximum of 64 characters. This of course is not set in stone and many servers will accept more than 64 characters for the local area of an address (the part before the @ sign). Domain names are limited to a maximum of 255 characters which is enforced by the domain registrars.

In the early days of the Internet, the local part of an SMTP address was most often in lowercase ASCII characters. For the most part they still are, but it looks as if system administrators bowing to corporate pressure (or something!), have allowed users to have their names with uppercase first characters. This creates a problem: Many people still have the idea that all email addresses are lowercase (which is technically wrong, but mostly accurate) and others believe they are case-sensitive (which is technically right, but mostly inaccurate). So because of this confusion system administrators are forced to make their domain policy case-insensitive such that users can have Chris@domain.com, chris@domain.com, CHRIS@domain.com and all other variations point to the same SMTP address. This effectively reduces the number of possible addresses available on a system. This is similar to the folder structure problem of UNIX and Windows web servers. On UNIX, the folder /Chris is different from /chris, while on IIS /Chris is the same folder as /chris.

According to RFC 2822, the local-part of the address may use any of these ASCII characters:
Uppercase and lowercase letters (case sensitive)
The digits 0 through 9
The characters ! # $ % * / ? | ^ { } ` ~ & ‘ + – =
The underscore _
The stop/period character . provided that it is not the first or last character in the local-part.

For the most part the upper and lower case characters, numerals and the period do not pose a problem for servers. Where problems occur is the use of the special characters: ! # $ % * / ? | ^ { } ` ~ & ‘ + – =. Have you ever seen an email address containing those? Probably not. For interoperability between operating system and mail system types, disallowing those characters is essential. There are some tricks to using those special characters, for example to use [ and ] they have to be encapsulated in quotations. [chris]@domain.com is invalid, whereas “[chris]“@domain.com IS. You can also have a space character if enclosed in quotations. Just stay away from these characters as people will be confused.

To combat spam, people have started typing their email addresses in forums and blogs as name[something]@doman.com, or [name]@domain.com. While some administrator must have in the past mentioned this as a good way to confuse email harvesters, it is no longer the case. Old harvesters used to rely on regular expressions and syntactically correct email structure to harvest addresses so emails with special characters would have been taken and recorded as verbatim. The address would have then been invalid since it wasn’t the user’s real address. Harvesters are now programmed with the idea that users are ignorant of email policy and throw special characters in their address to confuse spam-bots. They now automatically take those special characters out when harvesting addresses.

So what to do to confuse them? Put real words in the address that must be taken out. For example chrisssss@domain.com (take out the ssss) is more effective than chris[at]domain.com. It’s simply too bad for chrisssss@domain.com if there is such an address.

(No Ratings Yet)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>