Technical FAQ
If you're running into a problem and can't find an answer here, try the Troubleshooting
guide.
General
HexValidEmail
HexDns
HexTcpQuery
| Can HexGadgets work with proxy servers and firewalls? |
|
Proxies and firewalls are a complex subject, and the answer
greatly depends on your particular setup. HexGadgets do not
include any proxy-related provisions themselves.
- HexDns and HexLookup: You may have a DNS
server on your local network that they can use. Queries can
go through a firewall if it allows outgoing UDP traffic to
port 53.
- HexValidEmail: DNS validation uses HexDns, so the
statements above apply. For SMTP validations, you will
probably need either a direct path to the Internet or SOCKS
redirection software such as NEC's
SocksCap. Firewalls will need to allow outgoing traffic
to TCP port 25 (for SMTP).
- HexTcpQuery: For Whois and most other protocols, you will
probably need a direct path to the Internet or a SOCKS
redirector. For HTTP, however, you can probably use
the simple CERN proxy protocol:
To get our home page, you would normally connect to our
server on port 80 and send the following query:
GET / HTTP/1.0
To use a CERN proxy, you would connect to your proxy
server on the appropriate port and send this query:
GET http://www.hexillion.com/ HTTP/1.0
With CERN proxying, you use the normal HTTP protocol
but connect to the proxy server and specify a full URL.
Furthermore, because you're specifying a URL, you may able
access other protocols such as FTP through this mechanism.
For example:
GET ftp://ftp.microsoft.com/ HTTP/1.0
- HexIcmp: You will need direct ICMP access to the Internet
or some other provision.
|
|
 |
| Do you have HexGadgets for HTTPS, FTP, TELNET? |
|
Not at this time. If you have a proxy server, however, you may
be able to FTP files with HexTcpQuery. (See above.) |
|
|
|
Is it possible to make HexGadgets issue
multiple queries in parallel to save time?
|
|
Yes and no. The current HexGadgets only operate synchronously.
In other words, the executing thread cannot continue until a
method call has returned. Thus, HexGadgets will only be able to
do one thing at a time in a single thread (such as that of an
ASP request). If your programming system allows multiple
threads, however, you can simultaneously run a HexGadget
operation in each thread.
|
|
|
|
|
Do HexGadgets work with MTS and COM+?
|
|
Yes, but you will not be able to use runtime keys for the
HexGadgets in these environments because MTS/COM+ packages do
not support the IClassFactory2 licensing interface. Also,
HexValidEmail will not be able to use its runtime license for
HexDns, so you will need a separate license for HexDns in this
case. |
|
|
|
Why do HexGadgets require numeric IP addresses
instead of accepting domain names?
|
|
In short, HexGadgets use numeric IP addresses because it's a cleaner
design. Specifically, it
- Isolates different areas of functionality into different components, providing better
encapsulation and granularity. For example, you can have separate Timeout and Error
properties for lookups, TCP queries, ICMP communications, and so on, instead of having
them all lumped together.
- Avoids unnecessary string handling and conversions between strings and numbers.
- Allows a choice of lookup facilities instead of tying you to something built-in. You can
use HexLookup, HexDns, another 3rd party component, or your own code to look up IP
addresses.
- Clarifies network programming thinking. It enforces the distinction between domain names
and IP addresses and matches the way Internet communication actually works.
|
|
Why did the Validate method return success for an address I know doesn't exist?
|
|
A "successful" validation does not guarantee a good
email address. Each validation stage simply presents an
opportunity to find a problem. If you get as far as SMTP
validation and it doesn't return an error, you get the highest
possible confidence in the address without actually trying to
send email to it. (That's why we call the Validate return value
a "confidence rating".) Some SMTP servers will not
complain about bad addresses, so you cannot know that an address
is good without actually sending email to it and getting a
response from your intended recipient.
Take a look at our pages on interpreting
results and HexValidEmail
concepts for more details. |
|
|
|
|
Why would a mail server not reject a bad
address?
|
|
Some mail (SMTP) servers do not reject addresses of unknown
users for a variety of reasons, including:
- They're simply accepting mail to pass on to another server
and thus have no idea what users are valid on the
destination server. (This is often the case for secondary
servers for a domain.)
- The server has been configured to forward all unknown user
email to an administrator. Hexillion's mail server is set up
this way.
- Administrators have configured the server to accept any
username to prevent hackers and spammers from guessing
usernames and using SMTP to check their guesses.
|
|
|
| I have thousands of email addresses to
check. Can HexValidEmail handle that many? |
|
Yes. HexValidEmail is designed to be robust enough for high
volumes. However, validating thousands of addresses can take
days if you do the validations sequentially. Most of this time
will be spent waiting on replies from remote servers. Thus, to
validate thousands of addresses, you will probably need to
optimize your validation techniques. (See below.) |
|
|
| How can I speed up validations? |
|
Use optimizations such as these:
- Avoid needless DNS lookups by caching known-good domains.
Your local DNS server will do its own caching, so your cache
will probably have to reside in local memory to beat it.
- Avoid useless SMTP sessions by caching a list of domains
with mail servers that do not complain about bad addresses.
Skip SMTP validations for these domains because they will
always succeed.
- Reduce the SMTP timeout to 5 or 10 seconds. Fewer SMTP
validations will make it to completion, but your overall
validation times will drop dramatically.
- Run validations in parallel, using multiple threads.
|
|
|
| Can I select the DNS servers that HexValidEmail uses for MX record lookups? |
|
Yes. HexValidEmail uses the DNS servers listed in your Windows
TCP/IP properties, so you may want to put your desired servers there.
Alternatively, you can use a registry
key to specify your server addresses. |
|
|
| Why does a
SMTP validation succeed even when I can see that the VRFY and EXPN tests fail? |
|
HexValidEmail provides an option for sending VRFY and EXPN so
you can see the results with the SmtpSession
property. HexValidEmail ignores these results, however, and only
considers the response to the RCPT command. Occasionally you
will see cases in which the responses disagree.
HexValidEmail does not use VRFY and EXPN because they have
become quite unreliable as tests in recent years. Most
administrators disable them, but on different systems they give
different failure codes--even 2xx success codes sometimes. They
may also raise security flags for system administrators. We
recommend you leave this option off. |
|
How does HexTcpQuery compare to socket
components or specialized Whois, Finger, or HTTP components?
|
|
Socket components give you the ultimate in flexibility and control but
require you to handle all of the data transfer and higher-level protocol details yourself. A
specific application protocol component, such as an HTTP component, takes care of the communication
and protocol details but limits you to its implementation of that one protocol.
HexTcpQuery strikes a balance between the two extremes: it does the sending and
receiving work, but leaves the higher protocols to you. As it happens, common protocols such as
Whois and Finger are trivial to implement, and HTTP is not far behind. (Our
TcpQuery sample demonstrates how.) Thus,
HexTcpQuery seeks to provide the best of both worlds--it does most of the work for you,
but gives you the flexibility to work with multiple protocols. |
|
|
|
|
What APIs does HexTcpQuery use
internally--WinInet or direct Windows Sockets?
|
|
HexTcpQuery directly uses the Windows Sockets API. So do all
other HexGadgets except HexIcmp, which wraps the ICMP.DLL API. |
|
|
| Does HexTcpQuery support SSL,
TLS, or HTTPS? |
|
No. However, we may
offer an HTTP component with SSL support in the future. |
|
|
| Is HexTcpQuery HTTP/1.1 compliant? |
|
Strictly speaking, HexTcpQuery does not implement HTTP at
all--that's left to you.
Can it be used for HTTP/1.1? Yes, but with a few limitations
(it cannot maintain an open connection, for instance). We
recommend that you specify HTTP/1.0 in your queries. Using
HTTP/1.1 with HexTcpQuery will not provide much benefit over
HTTP/1.0 and may present some complications (such as content
chunking). |
|
|
| Will HexTcpQuery let me access a web site that
shares its IP address with other sites? |
|
Yes. Accessing such a site only requires that you include a
"Host" header in your HTTP query. Just contact the server through its IP address
as usual, sending it a request like the following: GET / HTTP/1.0[CRLF]
Host: www.SharedIP.com[CRLF]
[CRLF] |
|
|
| How can I
grab web pages other than the home
page? |
|
You simply need to put the resource location between the
"GET" and "HTTP/1.0" in your query.
GET / HTTP/1.0
Gives you the home page
GET /~bob/links.htm HTTP/1.0
Gives you Bob's link page.
|
|
