SMTP-Telnet

Weitere Seiten zum Thema:

Wir versenden Mails mit TELNET !

Da wir nun wissen, wo der Mailserver unseres Ziels steht, stellt sich die Frage, wie nun eine Mail dort hinkommen. Und genau das wollen wir hier machen. Wir spielen "Outlook Express" um diesen Vorgang von SMTP etwas zu entmystifizieren.

SMTP ist nichts anderes als eine Verbindung auf das andere System auf dem Port 25. Genau das wollen wir nun tun. Unser Hilfsmittel ist "Telnet". (Neue Versionen von "Hyperterm" können auch per WINSOCK eine Verbindung aufbauen und tun genauso. Also ran ans Werk:  TELNET eingeben.

Als Gegenstellen nehmen wir den Mailserver, den wir als Fehlerursache im Verdacht haben. Ich kann hier die IP-Adresse oder den Namen eingeben. Telnet fragt notfalls auch nach "A-Records". Wie wissen ja nun wie das geht. Im nächsten Feld steht "telnet" drin. Da tragen wir nun "25" als Port ein. Wenn wir "SMTP" eintragen, dann muss unser PC erst in der Datei "etc\services." nach dem Port suchen. Was sehen wir dann ?

Der andere Mailserver meldet sich und wartet auf meine Eingabe. Das kann manchmal einige Sekunden dauern. Einige Mailserver fragen nämlich zurück, wer ich bin und woher ich komme und ob ich nicht in einer Sperrliste stehe. Ehe wir nun was eingeben, sollten wir "lokales Echo" einstellen. Dann sehen sie, was sie selbst tippen.

Ich sende nun eine Testmail an mich selbst mit einem einfachen Körper ohne Umlaute, Anlagen oder andere Feinheiten. Für einen Test reicht das sowieso aus. Meine Eingaben sind blau die Ausgaben des Mailsystem sind rot. Die Nummern sind Rückgabecodes. Damit kann jedes System sauber die Antworten deuten, auch wenn die Meldungen z.B. in der Landessprache sind. Kommentare sind grün

Dies ist ein Test mit einem internen Mailserver mit absichtlich ungültigen Daten aus dem Jahre 2000. Heute sind solch einfache Tests oft nicht möglich, das Spamfilter wie NoSpamProxy viele Dinge prüfen und ablehnen.

telnet mail.netatwork.de 25  (bitte als Kommandozeile unter NT eingeben)

220 nawsv001.netatwork.de Microsoft ESMTP MAIL Service, Version: 5.0.2195.1600 ready at Sun, 19 Nov 2000 17:15:09 +0100 (Die Meldung kommt alleine. Etwas GEDULD)
helo mailhost.domain.tld (Das ist ihre erste Eingabe)
250 nawsv001.netatwork.de Hello [192.168.100.53] (und die erste Antwort)
mail from:<absender@domain.tld>  (Das ist die Absenderadresse, die sie vorgeben)
250 2.1.0 absender@domain.tld....Sender OK  (Wird bestätigt)
rcpt to:<empfaenger@domain.tld> (Hier hin soll die Mail gesendet werden)
250 2.1.5 empfaenger@domain.tld (Auch das wird bestätigt)
data   (hier bitte etwas warten, einige Mailserver und Contentfilter prüfen nun einige Daten)
354 Start mail input; end with <CRLF>.<CRLF>  (Nun sind sie an der Reihe)
Subject: Test per SMTP (Alles was sie nun noch tippen ist der der Mailheader, z.B. Datum etc.)

Nach einer Leerzeile beginnt der Body
(Eine Leerzeile beendet den Header)
Und er endet mit einem Punkt auf einer Zeile

.
(<<-----  Hier ist "nur" ein PUNKT und die Eingabetaste. Diese taucht nicht in der Mail auf)
250 2.6.0 <NAWSV001OeIiGXix4A20000011f@nawsv001.netatwork.de> Queued mail for delivery  (Der Mailserver hat die Nachricht akzeptiert)
quit (Nun beenden Sie sauber die Verbindung)
221 2.0.0 nawsv001.netatwork.de Service closing transmission channel

Verbindung zu Host verloren. (Das meldet dann ihr Terminal Programm)

(Meine Seite scheint sehr beliebt zu sein, denn anders kann ich mir nicht erklären, dass ich jede Woche einige Mails in meinem Posteingang finde. Ich finde lustig, dass einige das hier wirklich 1:1 abtippen. Das ist aber nicht der Sinn. Testen Sie einfach ihren Mailserver mit den passenden Werten damit. Das ganze sieht dann so aus (Wobei sich einige sogar hierbei vertippen :-)

Sie sehen also, wie unspektakulär SMTP in Wirklichkeit ist. Zur Erinnerung. SMTP wird genutzt um von ihrem Programm eine Mail bis zum Ziel zu übertragen. Jede Station dazwischen darf im Kopf ihren Stempel hinterlassen. Schauen sie sich einfach mal die Kopfzeilen einer empfangenen Mail an. Sie sehen genau, welchen Weg die Mail gelaufen ist.

Sie sehen auch, dass es bei SMTP eigentlich kein Kennwort oder Sicherheit gibt. Allerdings kann dies etabliert werden. Es gibt entsprechende Befehle um eine Anmeldung zu erzwingen. Ebenso sind Verschlüsselung per SSL und TLS möglich. Aber SMTP ist immer nur "senden". per SMTP können niemals Mails "abgeholt" werden. Befehle wir ETRN oder ATRN können der Gegenseite nur mitteilen, dass man empfangsbereit ist.

Nun nutzen Sie bitte nicht alle meinen Server zum Testen. Aber Sie sehen schon, SMTP ist nicht sicher, der Absender ist keineswegs garantiert und gegen Massenmails (Spam, UCE)) in meinem Mailbox gibt es auch keinen Schutz. Das ist wie bei der gelben Post. ich kann hundert Postkarten schreiben und an Sie senden. Als Absender kann ich alles mögliche drauf schreiben und Ihr Briefkasten wird auch zum bersten voll. Sie können nur anhand des Poststempels Rückverfolgen, wo diese Sendungen alle hergekommen sein könnten. Aber ich sehe von welcher IP-Adresse die Mail versendet worden ist. Und damit kann ich über den Provider und die Zeit durchaus herausbekommen, wer das war. Schade nur, wenn der Absender selbst ein "missbrauchtes" Relay war. Aber auch dieser hat Protokolldateien und ist sicher kooperativ, wenn ich ihm helfe seine "Dienstleistung" zu sichern.

Übrigens. Technisch kann jede gültige IP-Adresse (egal ob dynamisch oder statisch) SMTP direkt senden. Aber es gibt Provider und Firmen, die den Empfang von Nachrichten von "Wählzugängen" aufgrund hohem Missbrauch durch Spammer verhindern. Üblicherweise sendet eine dynamische Adresse mit Wählverbindung keine direkten Mail, sondern stellt diese per SMTP an den Provider zu, der dazu ein SMTP-Relay bereitstellt. Mit einer Wählverbindung solltest du also einfach deinen Provider fragen, an welche Rechner/IP-Adresse du deine ausgehenden Mails abliefern sollst. Es spart dir sogar noch Zeit und Volumengebühren.

Auf der Webseite http://www.ostrosoft.com/smtp_component/smtp_demo.asp gibt es sogar einen SMTP-Emulator, mit dem Sie üben können.

SMTP Smarthost und Routing

Nachdem Sie nun wissen, wie einfach der Versand einer Mail sein kann, möchte ich an einem erweiterten Beispiel zeigen,  dass es auch noch komplizierter geht.

Normalerweise werden Mails über den MX-Record an den richtigen Mailserver weiter geleitet. Aber ich kann, sofern ein Mailserver dies zulässt, auch die Mail an einen anderen Serverübergeben, damit dieser die Mail dann entsprechend seiner Konfiguration weiter gibt. Das ist dann die Funktion eines Smarthost.

Aber man kann SMTP auch direkt Leitwege mitgeben. Dazu dient eine besondere Adressierung beim RCPTO. Damit kann ich,  sofern der Mailserver dies zulässt, die Konfiguration des Mailservers aushebeln. Da dies aber meist als Missbrauch angesehen wird, haben viele Server diese Funktion deaktiviert. Und so geht es:

MAIL FROM:user1@example.com
RCPT TO: @Server1,@server2:user1@example.com

Eine solche Mail sollte von dem Mailserver dann an "Server1" gesendet werden. Der sendet sie weiter an "Server2" und dann per  MX zur Gegenstelle der Domäne "example.com". Damit  die Rückantwort natürlich auch wieder den Weg geht, ändern die Mailserver auch entsprechend die Absenderadresse. Der genaue weg ist dann.

SMTP-Auszug mein Absender zum Server0

MAIL FROM:user1@example.com
RCPT TO: @Server1,@server2:user1@example.com

SMTP-Auszug Server0 zu Server 1

MAIL FROM:@Server0:user1@example.com
RCPT TO: @server2:user1@example.com

SMTP-Auszug Server1 zu Server2

MAIL FROM:@server1,@Server0:user1@example.com
RCPT TO: user1@example.com

SMTP-Auszug Server2 zum Zielserver

MAIL FROM:@server2,@server1,@Server0:user1@example.com
RCPT TO: user1@example.com

Ganz schön kompliziert

SMTP Verben

Für jeden Befehl des SMTP-Protokolls gibt es eine klare offen gelegte Funktionsbeschreibung. Prüfen Sie aber, ob die RFC nicht durch eine aktuellere Version ersetzt wurde. Dies steht meist gleich am Anfang.

Auch die Fehlermeldungen sind standardisiert. Hier kommen einmal die Standard Codes mit dreistelligen Nummern zum Einsatz und immer mehr auch die erweiterten Codes

Weitere Links

Tags:SMTP Grundlagen Telnet