Wenn Sie diesen Titel lesen und schon mal mit Exchange (oder anderen Mailsystemen) zu tun hatten, schlagen Sie sicher die Hände über dem Kopf zusammen.

Es gibt User, die denken sie leiten Ihre Mails von A nach B automatisch weiter und rufen Sie von C ab um sie dann vom Client aus per Regelwerk an D weiterzuleiten und von E abzurufen…

Wenn wir nun irgendwann in dieser Schlange bei Z angekommen sind, sollte sich der User zum ersten Mal die Frage stellen, warum seine Mail “irgendwo im Nirwana” hängengeblieben ist.

Relativieren wir mal das Ganze:

Generell läßt sich erst einmal festhalten, dass Mails niemals “einfach verschwinden”. Es sei denn, das böse Exchange Eichhörnchen ist mal wieder unterwegs und sammelt Mails ein, um sie im Wald zu vergraben. 🙂
Sie werden mir sicher Recht geben, dass das eher unwahrscheinlich ist.

Das Wesentliche dabei ist das verwendete Protokoll.

SMTP – Simple Mail Transfer Protokoll – Ich bitte Sie das “simple” im Namen zu beachten. Es ist tatsächlich ein absolut einfaches Protokoll das aus der Zeit stammt als das Wort Gigabit höchstens in einem Science Fiction Roman vorkam.

Das ist alles relativ schnell erklärt:

• Mailserver A will an Mailserver B eine Nachricht senden.
• Mailserver A “ruft” Mailserver B an und sagt: “Hallo, ich bin Mailserver A”
• Mailserver B nimmt den Hörer ab und sagt: ” schon Dich zu hören, ich bin Mailserver B”
• Mailserver A sagt: “Ich hab eine Nachricht für für einen Deiner Benutzer von einem meiner Benutzer.”
• Mailserver B sagt: “Den Benutzer kenne ich, ich nehme die Nachricht an.”
• Mailserver A sagt: “Hier sind die Daten”
• Mailserver B sagt: “Ich habe alles empfangen”
• Dann sagen beide noch auf Wiedersehen und das Gespräch ist beendet.

Im Detail sieht das so aus:

telnet mail.server.com 25
Trying 192.0.2.10...
Connected to mail.server.com.
Escape character is '^]'.
220 mail.server.com ESMTP 
EHLO mail.server.com
250-mail.server.com
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN DIGEST-MD5 PLAIN CRAM-MD5
250-AUTH=LOGIN DIGEST-MD5 PLAIN CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:<test@Domain.com>
250 2.1.0 Ok
RCPT TO:<user@server.com>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Hier steht der Betreff

Hier steht die Nachricht

.
250 2.0.0 Ok: queued as 1322454835128
QUIT
221 2.0.0 
Connection closed by foreign host.

Soweit, so gut…

Das ist das Beispiel für eine erfolgreiche Mailübermittlung. vereinfacht gesagt ist die Antwort “250 OK” das, worauf der Absender wartet. Mit dieser Antwort ist alles OK

Es kann jetzt aber natürlich zu Fehlern kommen. Entsprechende Fehlercodes lassen sich im Internet schon zur Genüge finden. Zwei davon möchte ich aber kurz beschreiben.

1.) Unable to relay:

Gibt ein Empfänger diese Antwort zurück, heißt das, er ist nicht berechtigt für unauthorisierte Benutzer Mails an diese Domäne zu senden. Nicht mehr und nicht weniger. Damit komme ich “eigentlich” zu einem meiner Lieblingsthemen: SPAM, dazu aber an anderer Stelle mehr.

2. ) Unknown User:

Diese Antwort des Empfängers sollte “eigentlich” (schon wieder dieses Unwort) selbsterklärend sein. Der Empfänger kennt die Domäne, findet aber den User nicht.

Darüber hinaus gibt es noch einige Fehler, die sich aber zu Hauf im Internet finden lassen.

Wenn Sie nun von Benutzern die in der Überschrift genannte typische “Fehlerbeschreibung” genannt bekommen (ist der Papst eigentlich katholisch) dann läßt sich relativ einfach der Weg einer Mail verfolgen und Sie werden feststellen, dass in 99 % der Fälle der “Fehler” zwischen Bildschirm und Rückenlehne des Bürostuhls zu finden ist.