Allgemein:DasSimpleMailTransferProtocol
Das Simple Mail Transfer Protocol
Die Kommunikation per E-Mail wird als eine der wichtigsten Anwendungen des Internet gesehen. Vor allem im gewerblichen Umfeld ist sie unersetzlich geworden und hat sich neben anderen Kommunikationsverfahren wie Telefon, Telefax und Brief längst etabliert. Die entscheidende Rolle hierbei spielt das Simple Mail Transfer Protocol, kurz SMTP, welches den Versand und Transport der Nachricht regelt.
Wie bei vielen Protokollen aus den frühen Tagen des Internet wurde bei der Entwicklung weniger auf Sicherheit, sondern mehr auf Stabilität und Zuverlässigkeit geachtet. Als 1982 SMTP mit dem RFC 0821 zum Standard erklärt wurde, konnte sich wohl einfach niemand vorstellen, daÿ eines Tages massenhaft Mails verschickt und Absenderadressen gefälscht werden. Nur so ist zu erklären, daÿ es durch SMTP so leicht ist, Spam zu versenden. In den nun folgenden Abschnitten werden die Schwachpunkte von SMTP genauer dargelegt.
Eine kurze Einführung
Die aktuelle Fassung des Simple Mail Transfer Protocol wird im RFC 2821 beschrieben und stammt vom April 2001. Von Anfang an stand die Stabilität des Protokolls im Vordergrund; das zentrale Ziel ist die zuverlässige und leistungsfähige Übertragung von E-Mails. SMTP ist dabei nicht vom zugrunde liegenden Netzwerk abhängig, solange dieses einen gesicherten Transport bereitstellt, wie beispielsweise TCP. SMTP ist damit im OSI-Schichtenmodell oberhalb der Transportschicht anzusiedeln, vor allem in den Schichten 5 (Sitzungsschicht) und 6 (Darstellungsschicht). Eine wichtige Eigenschaft von SMTP ist dabei das sogenannte Mail-Relaying, der Transport von Nachrichten über verschiedene Netzwerke. Dadurch kann die Nachricht nicht nur auf direktem Weg zum Empfänger gelangen, sondern auch über mehrere Zwischenstationen, und das System kann �exibel auf Ausfälle und Unterbrechungen reagieren. Eine wichtige Rolle hierbei spielt der Mail eXchanger-Mechanismus des Domain Name System.
Die Kommunikation vom Absender einer E-Mail bis zum Empfänger stellt sich in der Regel wie folgt dar: Der Absender schickt die Nachricht mittels SMTP an einen Server (oft ein Mailserver eines Internetproviders), welcher sich um den Weitertransport kümmert. Die weitere Übertragung � eventuell über weitere SMTP-Server anderer Netzbetreiber erfolgt ebenfalls per SMTP bis zum Mailserver des Empfängers, bei dem die Nachricht zur Abholung durch den Empfänger mittels anderer Protokolle (z. B. POP3 oder IMAP) bereitliegt. Durch moderne, tragbare Geräte wie Mobiltelefon oder PDA (sog. Mobile Devices) ist der Versand und Empfang von E-Mails möglich, ohne direkt an das Internet angeschlossen zu sein. Insgesamt wird laut RFC 282113 zwischen vier verschiedenen Typen von SMTP-Systemen unterschieden:
1. Das Ursprungssystem, von welchem die Nachricht in das Transportsystem eingebracht wurde.
2. Das Zielsystem, auch Mail Delivery Agent (MDA) genannt, von welchem die Nachricht direkt
an den Empfänger gesendet oder durch diesen von dort abgeholt werden kann.
3. Eine Zwischenstation, oder Relay, welche zunächst als SMTP-Server agiert und die
Nachricht von einem SMTP-Client entgegennimmt, anschliessend selbst als SMTP-Client
tätig wird und sie ohne Modifizierung ausser dem Hinzufügen von Trace-Informationen
(Received-Header) an einen SMTP-Server weiterreicht.
4. Ein Gateway, welches eine Nachricht aus dem einen Transportsystem empfängt und an
einen Server in einem anderen Transportsystem weiterreicht, wobei eines der
beteiligten Transportsysteme SMTP verwendet.
Die Endpunkte der Kommunikationskette, bei denen die Nachrichten in das Transportsystem eingespeist bzw. daraus entfernt werden (also die Mailprogramme der Benutzer), werden als Mail User Agent (MUA) bezeichnet. Sie verfügen in der Regel nur über eine eingeschränkte SMTP-Funktionalität. Server, die für die Annahme einer E-Mail per SMTP zuständig sind, werden als Mail Transfer Agent (MTA) bezeichnet und müssen über die volle SMTP-Funktionalität verfügen.
Eine typische Übertragung einer Mail von Server zu Server per SMTP spielt sich dabei immer wie folgt in einem Request-Response-Zyklus ab:
1 220 pc12717.mathematik.uni-marburg.de ESMTP server ready.
EHLO moutng.kundenserver.de
3 250-pc12717.mathematik.uni-marburg.de Hello moutng.kundenserver.de; ¶
ESMTPs are:
250-TIME
5 250-SIZE 0
250 HELP
7 MAIL FROM:<user@example.de> SIZE=874
250 Sender and size (874) OK - send RCPTs.
9 RCPT TO:<user1@pc12717.mathematik.uni-marburg.de>
250 Recipient OK - send RCPT or DATA.
11 DATA
354 OK, send data, end with CRLF.CRLF
13 Received: from [137.248.121.158] (helo=pc12717.Mathematik.Uni-Marburg.DE)
by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis),
15 id 0MKwpI-1G1J2q3Xh7-00006s; Fri, 14 Jul 2006 10:29:08 +0200
Date: Fri, 14 Jul 2006 10:29:08 +0200
17 From: Roman Meisl <user@example.de>
Reply-To: Roman Meisl <user@example.de>
19 X-Priority: 3 (Normal)
Message-ID: <1384690538.20060714102908@example.de>
21 To: user1@pc12717.mathematik.uni-marburg.de
Subject: SMTP-Veranschaulichung
23 MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
25 Content-Transfer-Encoding: 7bit
X-Provags-ID: kundenserver.de abuse@kundenserver.de
27 login:9cfad2e2cf66172b135409a015bd7214
29 Hier beginnt der Text...
....und hier endet er
31 --
'Multiple exclamation marks,' he went on, shaking his head, 'are a
33 sure sign of a diseased mind.' (Terry Pratchett)
.
35 250 Data received OK.
QUIT
37 221 pc12717.mathematik.uni-marburg.de Service closing channel.
Zeilen, die mit einem dreistelligem Zahlencode beginnen (z. B. Zeilen 1, 3-
6, 8 usw.), sind Antworten des empfangenden Servers, Zeilen ohne Zahlencode
sind Befehle des Senders (z. B. Zeilen 2, 7, 9 usw.). Die Zeilen 13 bis 33
enthalten die eigentliche E-Mail, welche sich sich in den Header (Zeilen 13
bis 27) und den Body (Zeilen 29 bis 33) untergliedert. Beide Teile sind durch
eine Leerzeile (Zeile 28) getrennt.
Im folgenden Abschnitt werden die Begrife Sender oder Client für den Computer verwendet, welcher eine E-Mail übertragen möchte und somit die Kommunikation initiiert. Mit Empfänger oder Server wird der Computer bezeichnet, welcher die E-Mail empfängt (und für den Adressaten zwischenspeichert oder in einem späteren, von der aktuellen Übertragung unabhängigen Schritt an einen anderen Server weiterleitet 14). In der folgenden Ausführung wird eine typische SMTP-Sitzung mit den wichtigsten und häuffgsten Abweichungen beschrieben. Für einen vollständigen Überblick wird auf das RFC 2821 verwiesen.
Eine SMTP-Sitzung beginnt mit der Herstellung einer Verbindung vom Client zum Server, worauf dieser mit einer Statusmeldung (z. B. Rechnername, Serversoftware und -version, Datum und Uhrzeit) antwortet. Üblicherweise wird die Sitzung durch den Client mit dem EHLO-Befehl eröffnet, welcher darüber hinaus dem Server mitteilt, dass sog. Service Extensions unterstützt werden. Dieser Befehl sollte, muss aber nicht von beiden Seiten unterstützt werden, statt dessen kann auch das einfachere HELO verwendet werden. Mit dem Befehl MAIL FROM:<reverse-path>, welcher die Absenderadresse enthält, wird die Übertragung der E-Mail eingeleitet. Daraufhin folgt einer oder mehrere RCPT TO:<forward-path>-Befehle, anhand dessen der oder die Empfänger der E-Mail speziffziert werden. Nachdem der Sender den DATA- Befehl gesendet und der Empfänger diesen quittiert hat, kann der Transfer der Maildaten erfolgen. Mit einer Zeile, welche nur einen Punkt enthält wird die Übertragung beendet, und der Server kann die Maildaten und die Empfäneradressen verarbeiten, was von diesem mit einer 250 Data received OK-Meldung bestätigt wird.
An dieser Stelle kann entweder mit einem weiteren MAIL FROM-Befehl die Übertragung einer neuen E-Mail begonnen werden oder mittels RSET (Zur ücksetzen des Servers) und QUIT die Sitzung beendet werden. Die Antworten des Servers bestehen aus einem dreistelligen Statuscode gefolgt von einem erläuternden Text. Für die kommunizierenden Programme ist allein der Zahlencode ausschlaggebend, der Text dient nur der besseren Verständlichkeit und kann bei identischem Statuscode je nach Software variieren. Die Statusmeldungen lassen sich, wie in nachfolgender Tabelle dargestellt, in fünf Gruppen einteilen:
Code Bedeutung
**** *********
1yz Vorläufige Bestätigung; der Befehl wurde akzeptiert, benötigt
aber noch eine Bestätigung der in dieser Antwort enthaltenen
Daten. (Kann nur in Verbindung mit Service Extensions vorkommen.)
2yz Bestätigung; der Befehl wurde akzeptiert und verarbeitet. Weitere
Befehle werden erwartet.
3yz Einstweilige Bestätigung; der Befehl wurde akzeptiert, bedarf
aber weiterer Daten, welche in einem weiteren Befehl gesendet
werden müssen.
4yz Vorübergehender Fehler; der Befehl wurde aufgrund eines vor-
übergehenden Fehlers nicht akzeptiert. Eine spätere Wiederholung
ist möglich, der Sender sollte mit der Befehlssequenz neu
beginnen.
5yz Permanenter Fehler; der Befehl wurde aufgrund eines Fehlers
nicht akzeptiert, der Sender sollte diesen
Die nach dem DATA-Befehl übermittelten Daten umfassen die eigentliche E-Mail, bestehend aus Header und Body. Diese Daten bleiben unverändert bis auf die Tatsache, dass am Anfang der Headerzeilen eine Received-Headerzeile eingefügt wird, welche darüber Auskunft gibt, von welchem Host die Mail empfangen und von welchem sie gesendet wurde. Anhand dieser Headerzeilen - sofern sie nicht gefälscht sind - kann nachvollzogen werden, welchen Weg die E-Mail genommen hat.
Die restlichen während der SMTP-Sitzung ausgetauschten Daten, vor allem die Mailadressen aus dem Reverse-path und dem Forward-path, bilden den sogenannten Envelope, welcher bei jeder SMTP-Sitzung neu erstellt wird. Hat eine Nachricht mehrere Empfänger (mehrere RCPT TO-Befehle), wird für alle Empfänger am gleichen Bestimmungsort nur eine Kopie verschickt. Folgendes Beispiel veranschaulicht diesen Vorgang; die SMTP-Sitzungen sind auf den relevanten Teil gekürzt:
...
MAIL FROM :< sender@domain .tld >
250 2.1.0 < sender@domain .tld >... Sender ok
RCPT TO:< albert@destination .tld >
250 2.1.5 < albert@destination .tld >... Recipient ok
RCPT TO:< berta@destination .tld >
250 2.1.5 < berta@destination .tld >... Recipient ok
RCPT TO:< hans@another - dest .tld >
250 2.1.5 <hans@another - dest .tld >... Recipient ok
RCPT TO:< wurst@another - dest .tld >
250 2.1.5 <wurst@another - dest .tld >... Recipient ok
DATA
...
Diese Nachricht hat zwei Empfänger in der Domain destination.tld und zwei in der Domain another-dest.tld. Der Versand dieser Nachricht erfolgt in zwei getrennten Sessions. Zunächst der Versand der Nachricht nach destination.tld:
...
MAIL FROM :< sender@domain .tld >
250 mail from : < sender@domain .tld > ok
RCPT TO:< albert@destination .tld >
250 < albert@destination .tld > ok
RCPT TO:< berta@destination .tld >
250 < berta@destination .tld > ok
DATA
...
Und anschliessend eine Kopie nach another-dest.tld:
...
MAIL FROM :< sender@domain .tld >
250 2.1.0 < sender@domain .tld >... Sender ok
RCPT TO:< hans@another - dest .tld >
250 2.1.5 <hans@another - dest .tld >... Recipient ok
RCPT TO:< wurst@another - dest .tld >
250 2.1.5 <wurst@another - dest .tld >... Recipient ok
DATA
...
Das heisst, werden Kopien einer Nachricht benötigt, werden sie auf dem Verbreitungsweg so spät wie möglich erzeugt.
(DNS) im Zusammenhang mit SMTP
Das Domain Name System (DNS) hat neben der üblichen Namensaufösung beim Versand von E-Mails eine weitere Aufgabe. Wie in den RFCs 974, 1034, 1035 und 2821 beschrieben15, dient es auch als Verzeichnis für den oder die Maileingangsserver einer Domain. Hierfür steht ein gesonderter Resource Record zur Verfügung (MX-RR, Mail eXchange RR), anhand dessen die Mailserver spezifziert werden können:
DOMAIN . TLD .MX 10 SRV1 . DOMAIN . TLD .
MX 10 SRV2 . DOMAIN . TLD .
Diese Kon�guration besagt, dass die Hosts SRV1 und SRV2 für den Empfang von Mails an die Domäne DOMAIN.TLD. gleichberechtigt zuständig sind. Der Zahlenwert vor dem Hostnamen (hier jeweils 10) drückt die Präferenz aus. Er ist dabei als "Entfernung" zu verstehen; je kleiner er ist, desto grösser ist die Präferenz.
Sendende SMTP-Server sind verpfichtet, eine DNS-Abfrage nach einem MX-RR zu stellen, um das Ziel der Nachricht zu erhalten. Hierzu wird aus der Mailadresse des RCPT TO-Befehls der Domainname extrahiert und eine entsprechende Anfrage an den in der Konfguration des SMTP-Servers eingetragenen Nameserver gerichtet. Im Normalfall antwortet dieser mit einem oder mehreren MX-Records. Daraus erstellt der sendende SMTP-Server eine nach aufsteigendem Präferenzwert sortierte Liste und versucht, beginnend mit dem ersten Mailserver dieser Liste, die Nachricht zu verschicken. Im Fall eines erfolglosen Sendeversuches wird der nächste Server der Liste (mit möglicherweise höherem Präferenzwert) ausgewählt und ein neuer Sendeversuch unternommen.
Schwächen von SMTP
Folgende Eigenschaften des SMTP-Protokolls erschweren es dem Empfänger, sich gegen unerwünschte Nachrichten zu wehren, bzw. erleichtern den Versand von Spam:
Vielfältige Absenderangaben In den Headerzeilen einer E-Mail können insgesamt fünf verschiedene Absenderadressen stehen:
1. Der From-Header bezeichnet den Autor einer Nachricht, also die Adresse
jener Person oder jenes Systems, welches den Inhalt der Nachricht erstellt hat.
2. Der Sender-Header bezeichnet die Adresse, welche für das Versenden der
Nachricht verantwortlich ist. Dies könnte beispielsweise die Adresse
einer Sekretärin sein.
3. Der Reply-To-Header kann mit Einschränkungen ebenfalls zu den
Absenderangaben gezählt werden. Er gibt an, an welche Adresse
eventuell Antworten zu richten sind.
4. Der Resent-From-Header hat die gleiche Bedeutung wie das From-Feld im
Falle einer Umleitung. Er bezeichnet die Adresse des Autors, welcher
für die Umleitung verantwortlich ist.
5. Für den Resent-Sender-Header gilt entsprechendes.
Da keiner dieser Header vom empfangenden SMTP-Server hinzugefügt, sondern vom sendenden Server nach dem DATA-Befehl gesendet wird, können die Inhalte beliebig gefälscht werden.
Weitere Absenderinformationen können den sog. Trace-Fields, dem Return-Path und den Received-Headern entnommen werden. Der Return-Path enthält die Adresse aus dem letzten MAIL FROM-Befehl. Dieser Header wird vom letzten empfangenden Server hinzugefügt, der Inhalt kann aber durch entsprechend konfgurierte Sendesysteme beliebig gefälscht werden. An jeder Zwischenstation wird ein neuer Received-Header hinzugefügt; dieser enthält neben dem Hostnamen aus dem EHLO- bzw. HELO-Befehl und weiteren Details auch die IP-Adresse des sendenden Servers. Der Hostname kann wiederum durch spezielle Konfgurationen beliebig gefälscht sein. Die stärkste Aussagekraft hat die IP-Adresse 16), welche jedoch über Anonymisierungsdienste verschleiert werden könnte 17) . Da jedoch Received-Header nach dem DATA-Befehl übertragen werden, können speziell präparierte E-Mails mit beliebig gefälschten Received-Headern versehen werden, bevor die Nachricht in das Mailsystem eingeschleust wird. Dadurch wird dem tatsächlichen Übertragungsweg sozusagen ein Stück angehängt und damit dessen Überprüfung unmöglich gemacht. Letztendlich gibt es für den Empfänger keine praktikable Möglichkeit den Ursprung einer Nachricht zweifelsfrei festzustellen 18).
Fehlende End-to-End-Verbindung Wie im vorigen Abschnitt bereits angedeutet wurde, wird eine E-Mail fast immer über mehrere Zwischenstationen zum Empfänger gesendet. Als erstes erfolgt die Übertragung vom Host des Absenders zu seinem SMTP-Server. Dieser sendet die Nachricht an den dem Ziel am nächsten gelegenen SMTP-Server. Dies ist im Idealfall der des Empfängers, von dem dieser die Nachricht mittels eines POP- oder IMAPZugriffs empfangen kann. Um den Nachrichtentransfer gegen Störungen der Übertragungskanäle oder Serverausfälle abzusichern und so stabil wie möglich zu machen, können zwischen dem SMTP-Server des Senders und dem des Empfängers mehrere sog. SMTP-Relays liegen. Aber auch ohne diese Zwischenstationen verhindert das Fehlen einer End-to-End-Verbindung, dass der Empfänger vom SMTP-Protokoll unabhängige Möglichkeiten nutzt, um sich über die Herkunft einer Nachricht Gewissheit zu verschaffen.
16) Laut RFC 2821 ist SMTP unabhängig vom zugrundeliegenden Protokoll. De facto wird aber bei weitem der gröÿte Teil des Mailverkehrs über TCP/IP-Verbindungen übertragen. 17) Z. B. JAP der TU Dresden [69]. 18) IP-Adressen sind nicht an bestimmte Hosts gebunden (Dial-Up-Verbindungen). Der Weg über die Protokolldateien
Kontrolle der Datenmenge Die Kontrolle der gesendeten und zu empfangenden Datenmenge unterliegt allein dem Absender. Der Empfänger hat nur die Möglichkeit, eingegangene Nachrichten zu löschen. Verstärkt wird dieses Problem durch das Expandieren der Empfängerlisten aus den To-, CC und BCC-Feldern. Aus einer einzigen ausgehenden E-Mail können durch Angabe mehrerer Adressaten tausende oder sogar Millionen eingehende E-Mails werden. Dadurch werden der sowieso schon geringe Aufwand und die kaum vorhandenen Kosten für den Absender zum bedeutungslosen Faktor.
Protokollbasierte Rückmeldungen Im engen Zusammenhang mit obigem Abschnitt steht das Fehlen von protokollbasierten Rückmeldungen. Der Empfänger hat keine Möglichkeit, eine Nachricht zurückzuweisen oder anderweitig dem Absender bzw. dem sendenden MTA mitzuteilen, dass er die Übertragung abbrechen oder begrenzen soll.
Begrifsklärung
Spezielle SMTP-Anwendungen
Eine Anwendung welche SMTP implementiert kann je nach Einsatzzweck unterschiedliche Aufgaben erledigen, weswegen zur genaueren Unterscheidung verschiedene Begrife gebräuchlich sind. Die im Rahmen dieser Arbeit verwendeten Begrife werden anhand des folgenden Beispiels erläutert:
Example
Eine Mail wird von pc12147 über ma1.example.com an ma2.example.net
verschickt und von dort an ma3.subd.example.net weitergereicht, wo
sie von einem User des Rechners jmaxwell abgeholt wird.
Server Als Server oder SMTP-Server wird stets der Partner einer SMTPSitzung bezeichnet, welcher auf eingehende Verbindungen wartet und an welchen die Nachricht übertragen wird (ma1.example.com, ma2.example.net, ma3.subd.example.net).
Client Als Client oder SMTP-Client wird stets der Partner einer SMTPSitzung bezeichnet, welcher die Verbindung initiiert hat und welcher die Nachricht sendet (pc12147, ma1.example.com, ma2.example.net).
MTA Mail Transfer Agent (MTA) bezeichnet eine Software (bzw. Computer), welche über die gesamte SMTP-Funktionalität verfügt (ma1.example.com, ma2.example.net, ma3.subd.example.net).
MUA Mail User Agent (MUA) bezeichnet eine Software (bzw. Computer), welche nicht über die volle SMTP-Funktionalität verfügt. Typischerweise sind dies Anwendungen, mit welchen E-Mails verfaÿt oder gelesen werden (pc12147, jmaxwell).
MDA Ein Mail Delivery Agent (MDA) ist in der Regel der letzte MTA auf dem Weg einer E-Mail, also jene Instanz, welche die Nachrichten in die Mailboxen der Empfänger verteilt bzw. von welcher ein MUA eine E-Mail abholt (ma3.subd.example.net).
MSA Ein Mail Submission Agent (MSA) ist in der Regel der erste MTA auf dem Weg einer E-Mail, also jene Instanz, an die ein MUA eine E-Mail weiterreicht (ma1.example.com).
Border-MTA Der letzte MTA bei Verlassen bzw. der erste MTA bei Erreichen einer Domain oder Organisation wird Border-MTA bezeichnet (ma1.example.com, ma2.example.net).
Weiterleitungsmechanismen
Der Begrif des Forwarding bzw. Weiterleiten wird in vielen unterschiedlichen Situationen verwendet, bei der eine Nachricht von einer Mailsoftware zu einer anderen geschickt wird. Dementsprechend viele Begrife werden für diesen Vorgang verwendet, wie Umleiten, Weiterleiten, Relaying, Forwarding, Resending, Reintroducing, Redirecting und wohl noch einige mehr.
Es ist nicht Sinn dieses Abschnittes, mögliche Bedeutungen dieser Bezeichnungen zu erörtern, sondern die verschiedenen Fälle einer Weiterleitung darzustellen und im Einklang mit den einschlägigen RFCs klare Begrifsdefnitionen bereitzustellen.
Es gibt drei verschiedene Möglichkeiten, eine bereits empfangene Nachricht an ein anderes SMTP-System weiterzureichen, mit jeweils unterschiedlichen Auswirkungen auf die Headerzeilen.
1. Die E-Mail wird von einem Relay weitergereicht. Die Headerinformationen
ändern sich bis auf das Hinzufügen eines Received-Headers nicht.
2. Weiterleitungen, welche der Benutzer durch spezielle Konfgurationen
auf "seinem" SMTP-Server erreicht (z. B. durch Einsatz von procmail,
einer .forward-Datei für Sendmail, Mailinglisten). Je nach Methode
und Software fallen die Änderungen an den Headerzeilen etwas
unterschiedlich aus, in der Regel bleiben sie jedoch weitgehend
unverändert; meist wird ein 'Sender:'-Header hinzugefügt, manchmal
auch weitere Resent-Header.
3. MUA-Software besitzt meistens eine Weiter- bzw. Umleitungsfunktionalitat.
Je nach Implementierung fallen die Änderungen an den Headerzeilen
unterschiedlich aus.
Für diese drei Fälle einer Weiterleitung werden folgende Begrifsdefnitionen vorgeschlagen:
Relaying bezeichnet die Weiterreichung einer E-Mail durch einen MTA innerhalb des SMTP-Transportsystems auf dem Weg zum MDA des Empfängers. Das Relaying wird lediglich durch den Domain-Part der To-Adresse der eingehenden Mail, nicht aber durch den Local-Part beeinflusst.
Forwarding bezeichnet die Weiterleitung einer E-Mail an einen anderen SMTP-Server durch einen MDA oder eine Mailingliste. Welche Nachrichten einem Forwarding unterzogen werden, wird durch den Local-Part der To-Adresse der eingehenden Mail bestimmt.
Resending bezeichnet den Vorgang, wenn ein Benutzer unter Verwendung eines MUA die Kopie einer E-Mail an eine andere Adresse schickt. Leider wurde bislang in keinem RFC spezi�ziert, welche Headerzeilen bei welchem Weiterleitungsmechanismus wie zu ändern sind. Im RFC 282219 findet sich folgende im Zusammenhang mit obigen De- �nitionen problematische Bemerkung, welche zur Klärung des Unterschieds zwischen Resending und Forwarding beitragen soll:
"Reintroducing a message into the transport system and using resent
fields is a diferent operation from "forwarding". "Forwarding"
has two meanings: One sense of forwarding is that a mail reading
program can be told by a user to forward a copy of a message to
another person, making the forwarded message the body of the
new message. A forwarded message in this sense does not appear
to have come from the original sender, but is an entirely new
message from the forwarder of the message. On the other hand,
forwarding is also used to mean when a mail transport program
gets a message and forwards it on to a diferent destination for
final delivery. Resent header fields are not intended for use with
either type of forwarding."
Die erste Erläuterung zur Bedeutung von Forwarding steht in gewisser Weise im Widerspruch zu der Aussage, daÿ Resent-Header jeder Nachricht hinzugefügt werden SOLLTEN, welche durch einen Benutzer erneut in das Transportsystem eingebracht wurde.
Die zweite Erläuterung entspricht eher dem Relaying, was an der Verwendung von "[. . . ]for final delivery." festgemacht werden kann: die Nachricht ist also noch nicht an ihrem Bestimmungsort angekommen.
beschriebenen Weiterleitungsfällen ist dies jedoch der entscheidende Unterschied zwischen dem ersten Fall (Relaying) einerseits und dem zweiten und dritten (Forwarding, Resending) andererseits. Bei einer Weiterleitung durch einen MDA bzw. MUA (Fälle zwei und drei) ist die E-Mail bereits an ihrem durch den ursprünglichen Absender vorgegebenen Ziel angekommen, was bei einem Relay nicht der Fall ist. Da obige De�nitionen ansonsten im Einklang mit der Verwendung in anderen RFCs stehen, wird im Rahmen dieser Arbeit an diesen festgehalten und als mögliche Übersetzungen folgendes vorgeschlagen:
relaying - weiterreichen
forwarding - weiterleiten
resending - wieder oder erneut (ver)senden bzw. umleiten.
Zusammenfassung
SMTP ist ein überaus leistungsfähiges Protokoll, welches sich für den Versand von Nachrichten bewährt hat: Es arbeitet stabil, zuverlässig und schnell. Dass Spam zu einem so grossen Problem geworden ist, liegt daran, dass der Versand von Spam so einfach ist. Die Kosten und der Aufwand sind im Vergleich zu anderen Werbemassnahmen (Postwurfsendungen, Plakate, etc.) zu vernachlässigen, mögliche Zieladressen finden sich leicht mittels entsprechend programmierter Agenten im WWW oder im Usenet, das Verschleiern oder Fälschen des Absenders - um möglicherweise drohenden gerichtlichen Konsequenzen zu entgehen - stellt ebenfalls keine Schwierigkeit dar. Und nicht zu vergessen: Spam hat Erfolg, d. h. durch E-Mail-Werbung lässt sich Geld verdienen. Wenn nur 0,001% aller in Deutschland erhaltenen Spam-Mails - also eine von 1 Million Nachrichten - zu einem Umsatz von 20 Euro führt, bedeutet dies bei einem täglichen Aufkommen von 1 Milliarde Werbemails eine durch Spam generierte Umsatzsteigerung von 20 000 Euro. Dieses Rechenbeispiel dürfte der tatsächlichen Situation durchaus gerecht werden, wie verschiedene Meldungen und Urteile belegen.
Spam - im Sinne von unerwünschten Nachrichten - ist nicht vermeidbar. Die Initiative geht stets vom Absender (A) aus, deshalb ist der Empfänger (B) gezwungen, Nachrichten zunächst anzunehmen, im Gegensatz beispielsweise zum HTTP-Protokoll, bei dem der Informationsfluss zwar ebenfalls von A nach B erfolgt, die Initiative aber vom Empfänger ausgeht, da die Information zuvor angefordert wurde.
Auch wenn es aufgrund dieses Prinzips immer zu unerwünschten Nachrichten kommen kann und wird, gibt es inzwischen vielversprechende Ansätze und Vorschläge, mit deren Hilfe verhindert werden kann, dass diese vereinzelten E-Mails zu einem Spamproblem werden.
Wie teste ich einen Mail Server SMTP Port 25 mit Telnet?
Um einen SMTP Server auf Port 25 anhand Telnet zu testen kann folgendes durchgeführt werden:
NOTE Dieser Test basiert auf Linux dh. dieser Test wurde anhand "telnet" auf Linux ausgeführt!
Dabei ist folgendes zu berücksichtigen: Der MailServer "smtp.mydomain.ch" stellt den SMTP
Server dar der getestet werden soll. Der Server "mail.domain.ch" stellt den Server dar auf
dem der Test ausgeführt wird. Alle Fettgedruckten" Kommandos müssen im Telnet Dialog
eingegeben werden! Beim getestet SMTP Server handelt es sich um einen Microsoft Server.
# telnet [FQND des MailServers zB smtp.mydomain.ch] 25
Trying 212.59.153.125...
Connected to smtp.mydomain.ch (212.59.153.125).
Escape character is '^]'.
220 smtp.mydomain.ch Microsoft ESMTP MAIL Service ready at Fri, 11 Jul 2014 09:09:39 +0200
EHLO mail.domain.ch
250-smtp.mydomain.ch Hello [212.59.153.125]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH NTLM
250-8BITMIME
250-BINARYMIME
250 CHUNKING
MAIL FROM:user-0@domain.ch
250 2.1.0 Sender OK
RCPT TO:user-1@mydomain.ch
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Subject: Testnachricht
Dies ist ein Test
.
250 2.6.0 <ddf9ccfb-8afd-4351-97dc-75796476103f@smtp.mydomain.local> [InternalId=7107] Queued mail for delivery
QUIT
221 2.0.0 Service closing transmission channel
Connection closed by foreign host.
#