Hexillion
 

Technical FAQ

If you're running into a problem and can't find an answer here, try the Troubleshooting guide.

General

HexValidEmail

HexDns

HexTcpQuery

General

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.

HexValidEmail

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.

HexDns

Can I add and update DNS records with HexDns?
Does HexDns support RFC 2136?
Not at this time. HexDns focuses on simply retrieving resource records. Dynamic DNS updates are on the wish list for a future version.
Can I create a new zone with HexDns?
No. In fact, as of this writing, there is no Internet standard for creating new zones. You will need to find a solution specifically tailored to your DNS server software.
Does HexDns support zone transfers?
Can it do the equivalent of the "nslookup -ls" command?
Not at this time. Again, this feature is planned for a future version.

HexTcpQuery

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.

Show site map

contact us    privacy policy    legal information