Outlook Contacts Verifier. Check e-mail addresses contacts and mailing lists. Done whilst in the process of merging two documents

Outlook Contacts Verifier

EXCEL VIDEO TUTORIALS / EXCEL DASHBOARD REPORTS

Check e-mail addresses contacts and mailing lists. Done whilst in the process of merging two documents

Contacts Verifier

Contacts Verifier (CV) is the first add-in for Microsoft� Outlook� 2000 / 2002 (XP) / 2003 designed to monitor validity of e-mail addresses in the contacts. It is capable of checking your address-book throughout in a few minutes to notify you of the contacts that contain e-mail addresses which are no longer valid.

Contacts Verifier can:

delete dead emails from mailing list or delete contacts with dead emails;

mark contacts with red or white flags;

open contact details window to give opportunity to user to fix email address.

Since 2.0 version, Contacts Verifier also support validation of recipients list in Mail Merge Mode in Microsoft Outlook and Microsoft Word (version 2002 or later required for mail merge).

When checking an address, CV imitates sending a message to the address being checked, and after it receives the answer from a server (the address belongs to) as to whether the address exists or not, it terminates message sending and ends the session correctly. So, checking of an address is technically correct and cannot be noticed by the address owner. You can find comprehensive information on address checking technology in the article "Email Verification Technologies ".

Information is becoming more and more valuable in our rapidly changing world, and we hope you will find our software product useful and easy to deal with. Contacts Verifier can save time and money and it is a great troubleshooting tool for mail delivery problems.

System requirements
Microsoft Windows 95/NT4 or later
Microsoft Outlook 2000, 2002 (XP), 2003 or later
Direct internet connection, NAT or connection through Socks5 proxy server

The process of message delivery by a mail server consists of the two phases. First, it detects address of the mail server that receives messages for the recipient (further on referred to as Recipient's Server, RS). Then, it connects to that server using the SMTP protocol and transmits the message to it.

Mail domain (mail.com for the address [email protected]; "alex" here is a mailbox in the mail.com domain) name normally is different from name of the mail server that receives messages for that address. At the moment when this text was being written, messages for [email protected] were received by the servers mail-com.mr.outblaze.com and mail-com-bk.mr.outblaze.com. While computers with addresses mail.com and www.mail.com received no messages for no addresses. So, mail domain cannot be directly related to the mail server address, rather often messages are received by a computer with absolutely different name.

To find out RS address, a query is sent to the DNS service, which stores (besides other things) information about mail server that receives messages for each domain.

DNS is a distributed database. For example, DNS server ns1.outblaze.com stores all the information about mail.com, but it knows nothing about other domains, e.g. about hotmail.com. The server ns1.hotmal.com stores information about domain hotmail.com, but it knows nothing about other domains. There is a server responsible for all .com domains, it keeps information about the servers that store domain information in the .com zone.

Your ISP's DNS has no information about mail.com or hotmail.com. Therefore, when it receives a query about the name mail.com, it inquires the server responsible for the .com zone about address of the server that contains domain information for mail.com (it is ns1.outblaze.com), connects to that server and returns the answer to you. This way of query execution is referred to as recursive.

We are not going to enlarge upon DNS technology here (it is well described in numerous public sources). The fact important for us is that a query to the DNS service might come through several DNS servers scattered over the globe before you get the answer. And, after all, it's domain owner who is responsible for storage of information about it.

There is a common practice of caching DNS queries. Normally, DNS server remembers the recursive query results for a couple of days in order to reduce the DNS server loading to ensure faster query execution (the information about maximum possible number of days for the result caching is contained into answer to a query). This means that when DNS record suddenly changes, it might take several days before caches of other DNS servers on the Internet are updated and their users get the up-to-date information.

To check whether an e-mail address exists or not, it is necessary to perform the same two phases as a mail server does to deliver a message to a recipient. First, we need to find out address of the server that receives messages for the recipient. Then, we have to connect to the mail server and ask it if it can receive a message for the user with that particular address.

Unfortunately, this method allows detecting no more than about 2/3 of invalid addresses. The problem is that some mail servers receive all messages for their mail domains, but if a mailbox doesn't exist, a server notifies the sender via e-mail that the message is undeliverable.

Current statistics show that about 30% of detectable 2/3 of dead addresses can be detected in the first phase, and 70% can be detected in the second phase. On the average, the second stage takes 10 times longer and involves 5 times greater network traffic compared to the first phase. In fact, the two-stage checking requires as much time and traffic as sending of a small message to the address being checked.

Consider the both phases in more details. In the first phase, checking software analyses e-mail address syntax, identifies mail domain and inquires DNS server about mail server address for that domain. For interaction with DNS server UDP protocol is used, this protocol is faster than TCP, because it is not oriented to establishing connection between servers. Normally, DNS server inquiring time doesn't exceed 1..2 seconds. During that time, one packet with the query is sent (about 60 bytes including the packet heading) and one packet with the answer is received (it's size doesn't exceed 512 bytes; normally it's no more than 200..300 bytes). Obviously, in this phase all addresses with wrong syntax and address with non-existent domains are screened.

In the second phase connection is established with a mail server using the SMTP protocol (based on TCP). TCP is oriented to establishing connection, therefore the servers involved in the process first send service packets to establish connection. Once the connection is established, the servers exchange greetings (see the first three lines in the log below); then, the sender's address is submitted, and the receiving server confirms its readiness to receive a message from that address; after that, message recipient's address is submitted:

< 220-ns.watson.ibm.com ESMTP Sendmail AIX4.3/8.9.3/8.9.0
< 220 Thu, 22 Aug 2002 20:44:07 +0500
> HELO cisco.my.net
< 250-ns.watson.ibm.com Hello cisco.my.net [12.44.72.94],
< 250 pleased to meet you
> MAIL FROM:<[email protected]>
< 250 <[email protected]>... Sender is valid.
> RCPT TO:<[email protected]>
< 550 <[email protected]>... User unknown
> RSET
< 250 Resetting the state.
> QUIT

In this instance, the receiving server answered that user with the address [email protected] was unknown to it and refused to receive the message. After that, the serves exchanged commands to terminate the connection.

While checking the address, the servers sent to each other 10 messages with total size about 500 bytes; but to send all those messages, they had to exchange over 20 packets, so the total traffic was about 2K. Of note, most of the action time was spent on waiting for reply from the other server.

See Screen Shots

EXCEL VIDEO TUTORIALS / EXCEL DASHBOARD REPORTS

Excel Trader Package Technical Analysis in Excel With $139.00 of FREE software!

Microsoft � and Microsoft Excel � are registered trademarks of Microsoft Corporation. OzGrid is in no way associated with Microsoft