MAPILab
EnglishDeutschRussian
Sie sind hier: Home / Kundensupport / FAQ und Artikel / Actual Contacts for Outlook: Techno...

Actual Contacts for Outlook: Technologie der Überprüfung von E-Mail-Adressen

Der Prozess der Nachrichtenzustellung durch einen Mailserver besteht aus ywei Phasen. Zuerst wird die Adresse des Mailservers, der die Nachrichten empfangt, festgestellt (weiter im Text Empfangerserver, ES). Dann wird durch SMTP-Protokol die Verbindung zu diesem Server aufgebaut und die Nachricht ubertragen.

Der Name der Postdomain (mail.com in der Adresse alex@mail.com; "alex" ist hier die Mailbox auf der Domain mail.com) unterscheidet sich normalerweise von dem Namen des Postservers, der die Nachrichten fur diese Adresse empfangt. Zum Zeitpunkt der Verfassung dieses Artikels die Nachrichten fur alex@mail.com wurden von den Servern mail-com.mr.outblaze.com und mail-com-bk.mr.outblaze.comempfangen. Wahrenddessen empfangen die Computer mit Adressen mail.com und www.mapilab.com keine Nachrichten fur keine Adressen. Somit ist die Domain nicht direkt verwandt mit der Adresse des Postservers, mehr sogar, oft werden die Nachrichten von einem Computer mit absolut anderem Namen empfangen.

Um die ES-Adresse herauszufinden wird eine Anfrage an DNS-Dienst gesendet, welche (au?er anderen Sachen) die Informationen uber den Postserver fur jede Domain enthalt.

DNS ist eine Datenbank. Zum Beispiel der DNS-Server ns1.outblaze.com speichert alle Informationen uber mail.com, beinhaltet jedoch gar nichts uber andere Domains, z.B. hotmail.com. Der Server ns1.hotmal.com speichert Informationen uber die Domain hotmail.com, beinhaltet jedoch gar nichts uber andere Domains. Der fur alle .com Domains verantwortliche Server beinhaltet Informationen uber die Server, die Domaininformationen in der .com Zone speichern.

Ihre ISP’s DNS hat keine Informationen uber mail.com oder hotmail.com. Dazu, wenn eine Anfrage uber den Namen mail.comkommt, wird der fur die .com Zone verantwortliche Server uber die Adresse des Servers, der die Information uber mail.com (es ist ns1.outblaze.com) angefragt, und somit erhalten Sie seine Antwort. Diese Art der Anfrage gilt als rekursiv.

Wir werden hier nicht naher auf die DNS-Technologie eingehen, da sie in vielen offentlichen Quellen gut beschrieben ist. Die wichtige Tatsache fur uns ist, dass die Anfrage an DNS-Dienst durch viele verschiedene DNS-Server uberall auf der Welt durchlaufen kann, bevor Sie die Antwort erhalten. Und nach all dem, ist es der Domainbesitzer, der verantwortlich ist fur die Speicherung der Informationen daruber.

Es gibt eine allgemeine Vorgehensweise bei DNS-Anfragen. Normalerweise merkt der DNS-Server die Anfrageergebnisse fur mehrere Tage um die Zugriffs- und Ladezeiten zu verkurzen (Die Information uber die maximale Anzahl von Tagen ist in der Antwort auf die Anfrage enthalten). Dies bedeutet, dass falls die DNS-Aufnahme sich plotzlich andert, kann es mehrere Tage in Anspruch nehmen, bevor die Caches von anderen DNS-Servern im Internet aktualisiert werden, und die Nutzer die aktuellen Informationen erhalten.

Um zu prufen, ob eine E-Mail-Adresse existiert oder nicht, muss man die gleichen zwei Phasen simulieren, die der Postserver anwendet, um die Nachricht an den Empfanger zuzustellen. Zuerst mussen wir die Adresse des Servers, der die Nachrichten fur den Empfanger erhalt herausfinden. Dann mussen wir eine Verbindung mit diesem Server aufbauen, und anfragen, ob er die Nachricht fur den bestimmten Nutzer empfangen kann.

Leider ermoglicht diese Methode nicht mehr, als 2/3 der ungultigen Adresse festzustellen. Das Problem dabei ist, dass manche Postserver alle Nachrichten fur ihre Postdomains empfangen, aber wenn die Mailbox nicht existiert, der Absender per E-Mail informiert wird, dass die Nachricht unzustellbar ist.

Aktuelle Statistik zeigt, dass etwa 30 % der festgestellbaren 2/3 der toten Adressen in der ersten Phase festgestellt werden konnen und etwa 70 % in der zweiten Phase. Dabei ist es so, dass die zweite Phase etwa zehnmal langer als die erste dauert und etwas funfmal mehr Netzwerktraffic beansprucht. Daher bedarf diese 2-Phasen-Uberprufung etwa soviel Zeit und Traffic, wie der Versand kurzer Nachrichten an jede einzelne Adresse, die uberpruft werden muss.

Betrachten wir die beiden Phasen genauer. In der ersten Phase analysiert die Prufungssoftware die Syntax von der E-Mail-Adresse, identifiziert die Postdomain und fragt beim DNS-Server uber die Adresse des Postservers fur diese Domain an. Fur die Interaktion mit dem DNS-Server, wird das UDP-Protokoll genutzt. Dieses Protokoll ist schneller als TCP, weil es nicht von der standigen Verbindung zwischen den Servern abhangt. Normalerweise braucht die DNS-Anfrage nicht langer als 1-2 Sekunden. In dieser Zeit wird ein Paket mit der Anfrage (ca. 60 Bytes mit der Kopfzeile) gesendet und ein Paket mit der Antwort (Gro?e ist normalerweise ca. 200-300 Bytes, ubersteigt nie 512 Bytes) empfangen. In dieser Phase werden die E-Mail-Adressen mit der falschen Syntax oder nicht existierender Domain festgestellt.

In der zweiten Phase wird die Verbindung mit dem Postserver uber SMTP-Protokoll (basiert auf TCP) aufbaut. TCP orientiert sich auf die aufgebaute Verbindung. Dazu werden an die entsprechende Server die Servicepakete zwecks Verbindungsaufbau gesendet. Wenn die Verbindung aufgebaut ist, tauschen die Server die Begru?ungszeilen aus (siehe die ersten drei Zeilen unten); dann folgen der Absender, die Bereitschaft des Servers von dieser Adresse Nachrichten zu empfangen und der Empfanger:

< 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:
< 250 ... Sender is valid.
> RCPT TO:
< 550 ... User unknown
> RSET
< 250 Resetting the state.
> QUIT

In diesem Schritt der empfangende Server antwortet, dass die Adresse noshuchaddress@ibm.com nicht bekannt ist und verweigert den Empfang der Nachricht. Hiernach tauschen die Server die Befehle zur Trennung der Verbindung aus.

Beim Prufen der Adresse schicken sich die Server gegenseitig zehn Nachrichten mit der Gesamtgro?e von etwa 500 Bytes zu. Doch um diese Nachrichten zu senden mussen Sie 20 Pakete austauschen, somit betragt der Gesamttraffic ca. 2K. Dabei sei es anzumerken, dass die meiste Zeit fur das Warten auf die Antwort von anderen Server verwendet wird.

Kundensupport
Wünsche und Anregungen
FAQ und Artikel
 
 
Suche auf MAPILab.com:
Abonnieren Sie unser Newsletter:
E-Mail:
Schnelle Links zu MAPILab Software:
Reporting Lösengen
Outlook Add-Ins
Outlook Plugins
Office Addons

Software für SharePoint
Exchange Add-Ons
Groupware Tools
SharePoint Workflow