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 Test-Mail 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 für 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 müssenmails (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 sie können 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 AUTH

Wenn sie eine Mail "anonym" an einen Server einliefern, dann sollten Sie damit rechnen, dass der Server einen Spamfilter anwendet. Firmenserver erlauben intern meist nur eine Einlieferung nach vorheriger Authentifizierung. Dazu muss der Client natürlich wissen, welche Anmeldeverfahren der Server versteht.

Mit einem EHLO bekommt man das am einfachsten mit. Wenn der Server kein EHLO versteht, dann dürfte "PLAIN" das einzige Verfahren sein.

ehlo test
250-exch16.msxfaq.net Hello [192.168.4.2]
250-SIZE 37748736
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-AUTH GSSAPI NTLM LOGIN
250-8BITMIME
250-BINARYMIME
250 CHUNKING
451 4.7.0 Timeout waiting for client input

Hier sehe ich die Information, dass der Server GSSAPI, NTLM und LOGIN versteht aber kein "PLAIN". Damit kann ich mich bei dem Server zumindest nicht mit einem "Einzeiler" anmelden.

AUTH PLAIN
334
username:kennwort base64 codiert==
235 Authentication Successful

Aber er Unterstützt "LOGIN" was auch nicht viel aufwändiger ist. Eine reguläre Anmeldung per SMTP "LOGIN" beginnt dann mit AUTH, worauf der Server mit dem bas64 codierten String für "Username" antwortet. Nach der Eingabe des Usernames (ebenfalls Base64 codiert), antwortet der Server mit "Password". Das wird auch wieder per Base64 gesendet.

AUTH LOGIN
334 VXNlcm5hbWU6
VXNlck5hbWU=
334 UGFzc3dvcmQ6
UGFzc1dvcmQ=
235 2.7.0 Authentication successful

Das kann man als Admin auch per Telnet noch mal schnell umsetzen. BASE64 Encoder/Decoder gibt es ja genug im Internet, denen Sie aber nicht ihr Kennwort anvertrauen sollten. Dann doch besser per PowerShell die Strings umwandeln.

[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("UserName"))
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("Kennwort"))

SMTP Smuggling

Beachten Sie dazu auch die Seite SMTP Smuggling und Exchange

SMTP-Testprogramme

Wenn ihnen TELNET doch etwas zu Hardcore ist, dann gibt es durchaus verschiedene Werkzeuge zu testen eines Mailserver. Ganz vorneweg sind das natürölich die Kommandozeilenprogramme und PowerShell-CMDLets

Aber es gibt auch das ein oder andere kleine WindowsTool mit einer GUI

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.

  • rfc2821 für the basic specification of SMTP
  • rfc1123 für important additional information
  • RFC 2645 ATRN Authenticated TURN.
  • RFC 2554 AUTH Authentication.
  • RFC 3030 BDAT Binary data.
  • RFC 2821 DATA Data.
  • RFC 2821 EHLO Extended Hello.
  • RFC 1985 ETRN
  • RFC 2821 EXPN Expand
  • RFC 2821 HELO Hello
  • RFC 2821 HELP Help
  • RFC 2821 MAIL Mail
  • RFC 2821 NOOP No operation
  • RFC 2821 QUIT Quit
  • RFC 2821 RCPT Recipient
  • RFC 2821 RSET Reset
  • RFC 821 SAML Send and mail
  • RFC 821 SEND Send
  • RFC 821 SOML Send or mail
  • RFC 3207 STARTTLS
  • RFC 821 TURN Turn
  • RFC 2821 VRFY Verify
  • Und dann gibt es natürlich noch einige exotische Erweiterungen verschiedener Herstellern, die auf  http://smtpfilter.sourceforge.net/esmtp.html aufgelistet sind: "ESTMP Keywords and Verbs (commands) Defined - Fluffy the SMTPGuardDog - spam and virus filter für any SMTP server"

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

  • RFC 1893 und RFC 2034 Informationen über erweiterte Statuscodes
  • 200 (nonstandard success response, see rfc876)
  • 211 System status, or system help reply
  • 214 Help message
  • 220 <domain> Service ready
  • 221 <domain> Service closing transmission channel
  • 250 Requested mail action okay, completed
  • 251 User not local; will forward to <forward-path>
  • 354 Start mail input; end with <CRLF>.<CRLF>
  • 421 <domain> Service not available, closing transmission channel
  • 450 Requested mail action not taken: mailbox unavailable
  • 451 Requested action aborted: local error in processing
  • 452 Requested action not taken: insufficient system storage
  • 500 Syntax error, command unrecognised
  • 501 Syntax error in parameters or arguments
  • 502 Command not implemented
  • 503 Bad sequence of commands
  • 504 Command parameter not implemented
  • 521 <domain> does not accept mail (see rfc1846)
  • 530 Access denied (???a Sendmailism)
  • 535 SMTP Authentication unsuccessful/Bad Username or password
  • 550 Requested action not taken: mailbox unavailable
  • 551 User not local; please try <forward-path>
  • 552 Requested mail action aborted: exceeded storage allocation
  • 553 Requested action not taken: mailbox name not allowed
  • 554 Transaction failed

Weitere Links