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.
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:
-
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.
-
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.
-
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:
- 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.
- 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.
- 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.
- 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.
- 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:
- With all the variations in SMTP message text and response
codes, it is difficult to reliably detect the name and version
of server software
- 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.
|