Hexillion
 

Mail administrator FAQ

This page explains the SMTP session that referred you here and offers suggestions for handling such sessions.

If you have questions that are not answered here, please feel free to contact us.

Questions

Answers

What is HexValidEmail?
HexValidEmail is a software component designed for validating email addresses. It initiates SMTP sessions to check address acceptance but never actually sends email. It is a product that we have created and sell on this site.

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.

Why are you accessing my server?
Most likely, the traffic you see is coming from someone using our HexValidEmail component, not from us. The presence of "hexillion.com" in the HELO or MAIL FROM commands does not mean the traffic comes from us.
Is this abuse?

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.
Why is this user masquerading as Hexillion?
The user has probably not changed the default settings for the HELO and MAIL FROM commands. HexValidEmail uses "hexillion.com" in the defaults so it is sure to work correctly without customer intervention. We urge our customers to use their own information, but sometimes they are unaware of the issue and do not read the instructions.
How can I determine who is really behind this activity?
There are three methods:
  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.
What is the best way to block an abuser?
Here are ways to block a HexValidEmail abuser. They are ordered from most desirable to least:
  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.

Don't you know that many mail servers will return a success code no matter what recipient address you specify?
Yes, we are well aware of this fact and try to explain it to our users. Nevertheless, many servers will return an error for an unrecognized address and thus make the SMTP technique worthwhile.
Don't you know that VRFY and EXPN are disabled?
Yes, we are well aware of this fact and try to explain it to our users. HexValidEmail includes an option for trying the VRFY and EXPN commands but ignores the results. The option is meant only for occasional diagnostics, and we discourage our customers from using it for their regular validations. If you see someone using the VRFY and EXPN commands, he either blindly copied some sample code or didn't read the documentation.
Can't you force your customers to use their own HELO domains and MAIL FROM addresses?
No.
  • 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
Aren't you just supplying tools to spammers?
No. Almost all of our customers use HexValidEmail for reasonable, legitimate email address quality control. It is possible for spammers to use HexValidEmail, but:
  • 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.

Aren't you taking a risk by putting Hexillion in the HELO and MAIL FROM by default?
Yes, but consider the alternatives:
  • 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
Why don't you just skip mail servers running [insert your favorite server software]?
Two reasons:
  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?
Why don't you just remove the SMTP capabilities from HexValidEmail?
Because SMTP validations are a key part of HexValidEmail's value. They often provide the definitive answer that an address has gone stale and cause no harm when done properly.
Why don't you limit the rate at which addresses can be checked?
HexValidEmail is a component--an object. Maintaining state from one instance to the next is not feasible. Thus, HexValidEmail cannot keep track of how often it is called nor limit the frequency of validations. The real issue is how frequently HexValidEmail hits a particular mail server. Users should make an effort to control this in their software, and mail administrators should contact the users if things get out of hand.
Don't you know that double-opt-in mailing lists are the only acceptable kind, and that such lists need no additional verification?
While it might be nice if all mailing lists had double-opt-in security, that's not the reality of the world in which we live. 

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.

Show site map

contact us    privacy policy    legal information