Mail administrator FAQ

Our customers incorporate HexValidEmail into their web sites, internal applications, and commercial software products.  Sometimes they use it to check email addresses in real time as users enter them. Other times, they use HexValidEmail to check their large accumulated databases of addresses. The vast majority of our customers use HexValidEmail responsibly.

Seeing a few HexValidEmail sessions on your server is normal. If you're a large email address provider such as Hotmail, you may see a lot more.

Even if the email addresses being checked seem odd, a handful of validations does not constitute abuse. Remember, the whole point of validation is to separate addresses that work from those that don't. Presumably some of the addresses will be bad.

Abuse is one of the following:

• Guessing accounts with a long sequence of validations
• Too many validations too fast, disrupting the operation of your server

If you feel your server is being abused, here is what you can do:

• If the MAIL FROM email address is not a hexillion.com address, you may be able to contact the user directly. Bear in mind that they may actually be using commercial mailing list software that checks email addresses with HexValidEmail. In that case, the user may never have heard of HexValidEmail.
• Contact us with the hash code from the NOOP comments. We may be able to determine who licensed the component and forward your complaint. More about that below. Please understand that we do not know many of our users and cannot do investigations.
• Block the user using techniques described below.
• Contact the user's ISP as determined from the IP address.

1. Check the MAIL FROM address. If it isn't a hexillion.com address, it may be a valid email address for the user. Try contacting them directly if you have a complaint. Bear in mind that they may actually be using commercial mailing list software that checks email addresses with HexValidEmail. In that case, the user may never have heard of HexValidEmail.
2. Follow the IP address, which can usually reveal the user's ISP or employer. You can use our Domain Dossier utility to display relevant information for an IP address.
3. Send us the hash value from the SMTP session. HexValidEmail 1.2 and later places a secure hash (SHA1) of the user's license information (if any) in a NOOP comment in the SMTP session. It is a string of 40 hexadecimal digits. You may also see it in the local part of the MAIL FROM address if the user has not changed the default. If you send us this hash value, we may be able to determine which customer is behind the session. In that case, we will contact the customer and seek a resolution to the problem. If we cannot match a customer to the hash, you will have to fall back on the IP address.

1. Block or filter the IP address. This will usually stop the individual without affecting anyone else. The abuser can circumvent this measure by switching to a different IP address.
2. Block the full MAIL FROM address. For HexValidEmail 1.2 and later, this will stop the abuser and, in some cases, unlicensed HexValidEmail users. The abuser can simply change the MAIL FROM address to circumvent this.
3. Block an IP address range, such as the class C range containing the abuser's IP address. This risks shutting out innocent bystanders, but will prevent an abuser from simply using another IP address on his local network. The abuser will have to get an IP address that is further away in the address space.
4. Block sessions with a hexillion.com HELO domain. This will shut out all HexValidEmail users, even the many legitimate ones, until they change the default HELO domain. It will not block email from Hexillion, as none of our mail servers identifies itself as hexillion.com.
5. Block email with a MAIL FROM address @hexillion.com. This will shut out all HexValidEmail users, even the many legitimate ones, until they change the default MAIL FROM address. This will also block email from us and prevent us from helping you resolve the problem via email.

As you can see, none of these methods is bulletproof. Furthermore, approaches 4 and 5 can cause collateral damage without actually improving effectiveness. In general, the best approach is to concentrate on blocking IP addresses.

• It is impossible for HexValidEmail to reliably auto-detect the user's domain and email address.
• HexValidEmail has to allow for special circumstances (e.g., bounce message processing) that may require an adjustment of the HELO domain or the MAIL FROM address 

Therefore:

• HexValidEmail must offer a way for users to set the HELO domain and MAIL FROM address
• HexValidEmail cannot possibly verify or enforce what a user enters--it could be his information or someone else's

• HexValidEmail is not designed for spammers. Because it is just a component and not a standalone application, it requires additional software development. Also, it is designed for checking only one address at time and is not efficient for bulk harvesting. Thus, it is not the ideal tool for spammers when there are standalone bulk alternatives readily available.
• Our license agreement forbids abuse
• We have made a strong effort to communicate with both mail administrators and our customers to avoid and resolve conflicts. As of this writing, none of our competitors has even come close to making a similar effort.

If you think about it, any email software can be used for spam. The mere fact that spammers can use a software package doesn't mean it is designed for them, has no legitimate use, and should be discarded.

• We could use someone else's domain and email address (as at least one of our competitors does), thus shifting any suspicion to an innocent party
• We could leave the defaults blank, forcing our users to enter something before HexValidEmail will work. Our customers are generally not SMTP experts, so they will not expect or understand the need for this information without up-front education. This would lower customer satisfaction, increase our costs, and put us at a competitive disadvantage. The whole point of a component like HexValidEmail is to take the burdens of such details off the shoulders of our customers.
• We could try to live a 100% safe life, kill the product, and go home.

By using our own domain and email address, we:

• Ensure the best possible "out of box" experience for our customers
• Have a chance of being notified when someone abuses HexValidEmail

1. With all the variations in SMTP message text and response codes, it is difficult to reliably detect the name and version of server software
2. Why should we go to the trouble of detecting and avoiding a particular MTA when doing so primarily diminishes the value of our software?

Many companies will never accept having to send a confirmation email every time they collect an email address. It's hard enough to get people to provide contact information without adding hassle (and system complexity, and additional points of failure) to the process. Also, many users would tire of having to confirm every time. And novice users just wouldn't understand the process. Requiring confirmation is an example of trading user-friendliness for security, and many system designers will favor user-friendliness.

Also, confirming an email address at collection time doesn't mean the address will still be good in three months. Addresses go stale all the time. Sending additional confirmation emails periodically would add to everyone's email clutter, incur additional expenses, and in some cases be completely inappropriate. For example, some companies may simply want stats on the "decay" of their lists or a technical evaluation of a list they've rented.