Dateitransfer
mit HTTPDieser Abschnitt zeigt, wie Internet-Browser Informationen aus dem World Wide Web (WWW) per HTTP anfordern, wie HTML-Seiten grundsätzlich aufgebaut sind, wie man sie mit Script-Sprachen aufbohren kann und welche anderen Dienste es im Internet noch gibt. Mehr über das dabei benutzte TCP/IP-Protokoll und damit zusammenhängende Themen finden Sie in den Abschnitten Netzwerke sowie Geschichte der Kommunikation.
Dateitransfer
mit HTTPDas Hypertext Transfer Protocol, kurz HTTP, kennt jeder Internet-Benutzer schon von dem "http://", mit dem jede Adresse im World Wide Web beginnt. Damit weiß der Browser, welches Protokoll er benutzen muss, um Inhalte von einem bestimmten Server abzurufen - HTML-Seiten, Grafiken und sonstige Daten. In diesem Kapitel wird gezeigt, welches ganz einfache und leicht nachvollziehbare Verfahren dem HTTP-Protokoll zugrunde liegt.
| Die Themen dieses Abschnitts: | |
| Web-Adressen HTTP/1.0 HTTP/1.1 |
SSL, DES Server-Log RFC-Standards |
Bevor wir technische Details besprechen, zunächst noch ein kleiner Ausflug
zum Aufbau von Web-Adressen. Sicher ist Ihnen schon aufgefallen, dass deutsche
Adressen üblicherweise www.irgendwer.de lauten. Dahinter kann
noch eine Seitenangabe stehen, zum Beispiel www.shamrock.de/dfu/index.htm. In
der Adresszeile des Browsers lautet die Angabe in diesem Fall vollständig so:
https://handbuch.shamrock.de/dfu/index.htm
Diese Zeile besteht aus folgenden Bestandteilen:
| http:// www. shamrock .de /dfu/ index.htm |
Übertragungs-Protokoll Subdomain, hier Webserver Second-Level-Domain, ein Name Top-Level-Domain. z.B. Land Verzeichnispfad auf dem Server Name der gewünschten Datei |
Bei Domain-Namen spielt Groß- oder Kleinschreibung keine Rolle, shamrock.de kann also auch Shamrock.De geschrieben werden. Vorsicht: Im Gegensatz dazu reagieren Unix-/Linux-Webserver empfindlich auf eine abweichende Groß-/Kleinschreibung bei Verzeichnis- und Dateinamen, index.htm ist hier etwas anderes als INDEX.htm!.
Die folgenden zwei Tabellen nennen Top-Level-Domains (TLD), die bestimmten Ländern zugewiesen sind, sowie landesunabhängige wie .com oder .int. In einigen Fällen wird eine landesspezifische TLD wie etwa .tv für einen namensgleichen Geschäftsbereich (hier TV = Fernsehen) verwendet, auch wenn die jeweilige Firma ihren Sitz keineswegs in Tuvalu hat.
| Landesspezifische Top-Level-Domains | |
| ac=Ascension-Inseln ad=Andorra ae=Verein.Ar.Emirate af=Afghanistan ag=Antigua ai=Anguilla al=Albanien am=Armenien an=Niederl.Antillen ao=Angola aq=Antarktis ar=Argentinien as=Amerik. Samoa at=Österreich au=Australien aw=Aruba az=Aserbeidschan ba=Bosnien-Herzeg. bb=Barbados bd=Bangladesch be=Belgien bf=Burkina-Faso bg=Bulgarien bh=Bahrain bi=Burundi bj=Benin bm=Bermuda bn=Brunei bo=Bolivien br=Brasilien bs=Bahamas bt=Bhutan bv=Bouvet-Insel bw=Botswana by=Belarus bz=Belize ca=Kanada cc=Cocos-Inseln cd=Kongo cf=Zentralafrik.Rep. cg=Kongo ch=Schweiz ci=Elfenbeinküste ck=Cook-Inseln cl=Chile cm=Kamerun cn=China co=Kolumbien cr=Costa Rica cu=Kuba cv=Cap Verde cx=Weihnachtsinsel cy=Zypern cz=Tschechien de=Deutschland dj=Dschibuthi dk=Dänemark dm=Dominica do=Dominikan. Rep. dz=Algerien ec=Ecuador ee=Estland eg=Ägypten eh=West-Sahara er=Eritrea es=Spanien et=Äthiopien eu=Europa fi=Finnland fj=Fiji-Inseln fk=Falkland-Inseln fm=Mikronesien fo=Faroe-Inseln fr=Frankreich ga=Gabun gd=Grenada ge=Georgien gf=Frz.-Guiana gg=Guernsey gh=Ghana gi=Gibraltar gl=Grönland gm=Gambia gn=Guinea gp=Guadeloupe gq=Äquat.-Guinea gr=Griechenland gs=Georgia+Sandw.I. gt=Guatemala gu=Guam gw=Guinea-Bissau gy=Guyana hk=Hong Kong hm=Heard/McDonald hn=Honduras hr=Kroatien/Hrvatska ht=Haiti hu=Ungarn id=Indonesien ie=Irland il=Israel im=Insel Man in=Indien io=Ind.Ozean/britisch iq=Irak ir=Iran is=Island it=Italien je=Jersey jm=Jamaica jo=Jordanien jp=Japan ke=Kenia kg=Kirgisistan kh=Kambodscha ki=Kiribati km=Komoren kn=St.Kitts+Nevis kp=Korea (Nord) kr=Korea (Süd) kw=Kuwait ky=Kaiman-Inseln kz=Kasachstan la=Laos |
lb=Libanon lc=Santa Lucia li=Liechtenstein lk=Sri Lanka lr=Liberia ls=Lesotho lt=Litauen lu=Luxembourg lv=Lettland ly=Libyen ma=Marokko mc=Monaco md=Moldawien me=Montenegro mg=Madagaskar mh=Marshall-Inseln mk=Mazedonien ml=Mali mm=Myanmar mn=Mongolei mo=Macau mp=Nördl. Marianen mq=Martinique mr=Mauretanien ms=Montserrat mt=Malta mu=Mauritius mv=Malediven mw=Malawi mx=Mexiko my=Malaysia mz=Mozambique na=Namibia nc=Neu Kaledonien ne=Niger nf=Norfolk-Insel ng=Nigeria ni=Nicaragua nl=Niederlande no=Norwegen np=Nepal nr=Nauru nu=Niue nz=Neuseeland om=Oman pa=Panama pe=Peru pf=Frz. Polynesien pg=Papua Neuguinea ph=Philippinen pk=Pakistan pl=Polen pm=St.Pierre/Miqelon pn=Pitcairn-Insel pr=Puerto Rico ps=Palästina pt=Portugal pw=Palau py=Paraguay qa=Qatar re=Reunion-Insel ro=Rumänien rs=Rep. Serbien ru=Russische Föd. rw=Ruanda sa=Saudi-Arabien sb=Solomon-Inseln sc=Seychellen sd=Sudan se=Schweden sg=Singapur sh=St. Helena si=Slovenia sj=Svalbard/J.Mayen sk=Slowakei sl=Sierra Leone sm=San Marino sn=Senegal so=Somalia sr=Surinam st=Sao Tome/Principe sv=El Salvador sy=Syrien sz=Swaziland tc=Turks.Ciacos I. td=Tschad tf=Frz. Süd-Territ. tg=Togo th=Thailand tj=Tadschikistan tk=Tokelau tm=Turkmenistan tn=Tunesien to=Tonga tp=Ost-Timor tr=Türkei tt=Trinidad+Tobago tv=Tuvalu tw=Taiwan tz=Tansania ua=Ukraine ug=Uganda uk=Großbritannien um=US Minor I. us=USA uy=Uruguay uz=Usbekistan va=Vatikan vc=St.Vincent+Gren. ve=Venezuela vg=Virgin I.(britisch) vi=Virgin I.(USA) vn=Vietnam vu=Vanuatu wf=Wallis+Futuna I. ws=West-Samoa ye=Yemen yt=Mayotte yu=Jugoslawien za=Südafrika zm=Sambia zr=Zaire zw=Zimbabwe |
| Landesunabhängige Top-Level-Domains | |
| aero=Airlines arpa=Arpanet biz=Geschäftlich com=Kommerziell coop=Kooperation edu=Bildung gov=Regierung info=Info-Dienst |
int=International mil=Militär (US) museum=Museum name=Eigennamen nato=NATO net=Provider org=Organisation pro=Professionell |
HTTP (definiert in RFC 1945) benutzt eine ziemlich einfache Syntax. Sie können das mit Windows, Unix oder Linux gelieferte Telnet-Programm benutzen, um nach dem Herstellen einer DFÜ-Netzwerk-Verbindung genau mitzuverfolgen, was passiert. Das ist natürlich nicht so komfortabel wie mit einem Web-Browser, aber man kann den Dialog zwischen Client und Server ganz einfach manuell simulieren. Im folgenden Beispiel sind Ihre Eingaben fett geschrieben; achten Sie bitte genau auf die angegebene Groß- und Kleinschreibung beim Befehl GET und dem dahinterstehenden Dateinamen:
Telnet-Start mit Web-Adresse+Portnummer:
c:\>telnet www.space.net 80
Eine Seite anfordern:
GET /index.htm HTTP/1.0 (und 2 x Enter)
Der Server liefert zunächst den HTTP-Header...
HTTP/1.0 200 OK
Date: Mon, 27 Mar 2007 18:17:14 GMT
Server: Apache/1.3.1
Content-type: text/html
Content-length: 5921
Last-modified: Fri, 24 Jul 2003 12:15:01 GMT
...und dann den Seiten-Inhalt:
<html><head>...</head><body>...
</body></html>
Connection: close
Dann erscheint die Telnet-Meldung: Verbindung beendet.
Sie können danach das Telnet-Programm wieder beenden bzw. die Verbindung später erneut aufbauen. (Wenn Sie in der GET-Zeile den Parameter "HTTP/1.0" weglassen, ist das Verhalten undefiniert und von der Server-Software abhängig: Manche Server brauchen hinter GET in diesem Fall nur ein statt zwei Return-Zeichen und liefern dann auch sofort den Inhalt der Seite ohne einen vorangestellten HTTP-Header. Die gezeigte GET-Zeile funktioniert nicht mit jeder Domain, insbesondere nicht mit solchen Webservern, die mehrere Domains unter derselben IP-Adresse verwalten - dafür ist HTTP 1.1 erforderlich, siehe weiter unten.) - Das Beispiel zeigt immerhin bereits ein paar typische Eigenschaften einer HTTP-Verbindung:
Was der Browser mit den auf den Header folgenden Nutzdaten anfangen soll, erkennt er nicht primär an der Datei-Endung wie etwa .htm, .gif oder .jpg, sondern am "Content-type", den man auch oft MIME-Typ nennt. Dadurch kann er sinnvoll reagieren, wenn etwa der Web-Server zum Beispiel eine angeforderte Grafikdatei nicht findet und statt ihrer eine Error-Seite als Text zurückliefert.
Außer GET unterstützt HTTP/1.0 auch den Befehl HEAD; er wirkt wie GET, liefert aber nur den HTTP-Header ohne die Nutzdaten zurück. Damit kann ein Browser feststellen, ob sich die Seite gegenüber dem letzten Abruf geändert hat, und braucht sie ggf. nicht erneut komplett zu laden, sondern kann sie aus der lokalen Cache-Datei holen. Mit PUT kann man schließlich eine Datei zum Server senden, wobei man sich - wenn diese Methode überhaupt freigeschaltet ist - noch mit Benutzername und Passwort identifizieren muss.
Ein Sonderfall ist, wenn die Domain ohne expliziten Dateinamen oder mit einem Unterverzeichnis-Namen ohne Schrägstrich dahinter eingegeben wird, zum Beispiel so:
c:\>telnet www.space.net 80
GET /produkte HTTP/1.0
"produkte" ist hier ein Verzeichnis. 2 x Enter nicht vergessen! Der Web-Server antwortet nicht mit "OK", sondern mit "Found", und gibt dann mit "Location" auch an, wie man den Inhalt abrufen kann.
HTTP/1.0 302 Found
...
Content-length: 55
Content-type: text/html
Location: /produkte/
Hinterher gibt der Server noch eine Mini-Seite aus, die der Browser aber ignoriert.
<HTML><BODY>
Directory request redirected.
</BODY></HTML>
In diesem Fall muss der Browser anhand der Location-Angabe mit "GET /produkte/" das Dokument erneut anfordern. Deshalb wird zum Beispiel die Seite www.altavista.com/ schneller geladen als www.altavista.com ohne Schrägstrich! Neben den oben vorkommenden Status-Codes 200 und 302 gibt es noch eine Reihe anderer. Die wichtigsten sind:
200 = OK
206 = Partial content
301 = Found, moved permanently
302 = Found, moved temporarily
304 = Not modified
400 = Bad request
401 = Unauthorized
403 = Forbidden
404 = Not found
405 = Method not allowed
500 = Internal server error
501 = Not implemented
503 = Service unavailable
Der Code 206 (partial content) resultiert aus einem
Request-Header mit einer Angabe wie etwa:
GET /test.htm
bytes=4984 to 9122
Damit fordert der Browser den Server auf, nur einen bestimmten Teil der Datei
zu senden, um beispielsweise nach einem abgebrochenen Download nur den noch
fehlenden Rest zu übertragen.
Der Code 304 (not modified) wird zurückgeliefert, wenn ein Browser beim GET-Befehl im HTTP-Header ein Feld "if-modified-since:" mit Datum und Uhrzeit der in seinem Cache vorhandenen gleichnamigen Datei mitliefert und der Server anhand dieser Angabe feststellt, dass es keine neuere Version davon gibt, so dass es nicht sinnvoll ist, die Datei erneut zu übertragen.
Das ursprüngliche HTTP-Protokoll 1.0 wurde mit HTTP/1.1 (RFC 2068) in einigen Details verbessert und erweitert:
Zur Unterscheidung, welche Protokollvariante benutzt wird, kann man jedem Befehl entweder HTTP/1.0 oder HTTP/1.1 nachstellen. Mit folgender Anforderung kann ein Browser die Startseite der virtuellen Domain petershausen.de holen (ein Schrägstrich / holt die Startseite, typischerweise index.htm, index.html oder default.html):
Start des Telnet-Programms:
c:\>telnet www.shamrock.de 80
oder: telnet www.petershausen.de 80
Anforderung der Startseite von www.petershausen.de:
GET / HTTP/1.1
Host: www.petershausen.de
Der Server antwortet dann mit Header und Seiteninhalt
HTTP/1.1 200 OK
Date: Mon, 27 Mar 2000 18:17:14 GMT
...
Vergessen Sie bitte nicht, nach der Host:-Zeile zweimal Enter zu drücken, wenn Sie das per Telnet probieren - damit weiß der Server, wo Ihr Anforderungs-Block endet. Die Host-Zeile ist wichtig, da auf einem Server und damit auf einer IP-Adresse mehrere virtuelle Domains erreichbar sein können.
Zur Übertragung von sicherheitskritischen Informationen wie etwa Kreditkarten-Daten wird eine zusätzliche Protokollschicht zwischen dem TCP/IP- und dem HTTP-Protokoll eingefügt, nämlich der Secure Socket Layer (SSL). Web-Seiten, die diese Technik benutzen, erkennt man am vorangestellten "https:" statt "http:".
Eine sichere SSL-Verbindung wird von den meisten Browsern mit einem kleinen Vorhänge-Schloss am unteren Fensterrand gekennzeichnet. Dabei ist nicht nur die Verschlüsselung als Sicherheit zu nennen, sondern vor allem auch, dass der Domain-Inhaber bei einer öffentlichen Zertifizierungs-Instanz aufgrund entsprechender Nachweise zeitlich begrenzt (typischerweise jeweils für ein Jahr) als vertrauenswürdig eingestuft wurde. Die Zertifizierung kann betrügerischen Firmen jederzeit wieder entzogen werden. Vor allem deshalb sollte man bei Online-Bestellungen möglichst nur SSL-Seiten benutzen.
Der Client-Browser überprüft die Server-Identität jeweils mit Hilfe dieser Zertifizierungs-Instanz (Certification Authority) und benutzt unterschiedliche Verfahren mit Schlüssel-Längen von 40 bis 168 Bit zur Verschlüsselung der übertragenen Daten:
Das benutzte Public-Key-Verfahren funktioniert so: Der Client-Browser sendet dem Server eine Zufallszahl. Dieser wendet auf die Zahl einen beiden Seiten bekannten Algorithmus an (eine Rechenvorschrift) und sendet das Ergebnis dem Client zurück. Da der Client das richtige Ergebnis kennt, ist damit eine fälschungsssichere Identifizierung des Servers möglich, obwohl der Schlüssel in Form der Zufallszahl quasi öffentlich im Internet übertragen wird.
Wenn Sie einen eigenen Web-Server oder eine Domain bei einem Internet-Provider haben, können Sie anhand der Server-Logs regelmäßig sehen, wie oft welche Seite aufgerufen wurde. Dabei ist allerdings Vorsicht angebracht: In Wirklichkeit könnte die jeweilige Seite wesentlich öfter abgerufen worden sein. Wenn ihr Inhalt nämlich bei einem Cache-Proxy mit Cache zwischengespeichert wurde, erscheint nur ein einziger Proxy-Zugriff im Log, nicht aber die vielen Zugriffe der Benutzer auf den Proxy. Andererseits sagt die Statistik aber auch nichts darüber aus, ob die Besucher die Seite tatsächlich gelesen oder gleich wieder weggeklickt haben.
Viele Internet-Provider bereiten das recht unübersichtliche, umfangreiche Server-Log als Text-Zusammenfassung oder sogar mit Grafiken so auf, dass man auf einen Blick erkennen kann, was am häufigsten abgerufen wurde. Dabei werden einige Begriffe benutzt, die oft auch bei Werbung im Web als Tarif-Grundlage dienen:
Falls im Server-Log auch Verweise von anderen Web-Domains aufgeführt sind (Referrer), können Sie sehen, mit welchen Suchbegriffen Benutzer von Suchmaschinen auf Ihre Seiten gelangt sind. Im folgenden Beispiel hat jemand mit Fireball nach "windows freeware" gesucht; teilweise in einer grafisch aufbereiteten Statistik auch direkt die Suchbegriffe aus solchen Referrer-Zeilen angezeigt:
http://suche.fireball.de/fcgi/query.fcg?action=query&pg=express&q=+windows+freeware&submit=suchen&what=german_web
Oft erscheint im Server-Log ein Abschnitt mit "umgeleiteten Anfragen" (redirected requests). Wenn beispielsweise jemand einfach nur www.domain.de im Browser eintippt, wird sein Browser auf www.domain.de/ (man beachte den Schrägstrich am Ende) umgeleitet, wie das unter HTTP 1.1 bereits beschrieben wurde. Das ist kein Fehler, sondern völlig normal.
Interessant ist im Log auch die Statistik, welche Browser für das Laden Ihrer Seiten benutzt wurden. Sie können damit besser beurteilen, ob es sich (noch) lohnt, im Seiten-Layout bzw. in Scripts auf ältere oder seltenere Browser Rücksicht zu nehmen.
Zum Thema Datenschutz sei angemerkt: Bei einem Web-Surfer, der sich über einen Internet-Provider einwählt und dem dabei dynamisch eine IP-Adresse zugewiesen wird, enthält das Server-Log keinerlei personalisierte Daten. Es ist nicht möglich, die jeweilige Person zurückzuverfolgen. Man sieht also lediglich, wie oft bestimmte Seiten angesehen und welche Browser benutzt wurden, aber nicht von wem. Lediglich in begründeten Ausnahmefällen kann man den Anrufer vom Provider (z.B. T-Online) anhand von IP-Adresse, Datum und Uhrzeit zurückverfolgen lassen.
Eine Beschreibung der im Internet benutzten Standards wäre unvollständig, wenn dabei nicht erwähnt würde, wie sie zustande kamen. RFC heißt "Request for Comment", zu deutsch "Bitte um Kommentar", und bezeichnet die der Internet-Gemeinde zugeleiteten Standardisierungs-Vorschläge. Diese werden einfach durchnumeriert und tragen Namen wie RFC 1 (das allererste Papier aus dem Jahr 1969 mit dem Titel "Host Software"), RFC 2 und so weiter.
Internet-Pionier Jon Postel war von 1969 bis 1998 RFC-Redakteur; heute kümmert sich eine Gruppe mehrerer Personen im Auftrag der Internet Engineering Task Force IETF darum (siehe http://www.rfc-editor.org). Unter dieser Web-Adresse findet man auch die bisherigen RFC-Dokumente. Alle sind in englischer Sprache verfasst. Nicht alle sind allerdings Definitionen von Standards: Einige haben experimentellen Charakter oder beschreiben allgemeine Zusammenhänge des Internet, zum Beispiel gibt RFC 2505 Tipps zur Vermeidung von unerwünschten Werbe-Mails.
Neben dem im World Wide Web benutzten HTTP-Verfahren definieren RFC-Dokumente auch das Übertragen von E-Mails mit SMTP und POP3 sowie den Dateitransfer mit dem FTP-Protokoll. Diese Themen werden im folgenden Abschnitt behandelt.
Der folgende Abschnitt beschreibt einige weitere typische Internet-Dienste, ohne einen Anspruch auf Vollständigkeit zu erheben; so bleibt etwa das veraltete Gopher-Protokoll unerwähnt. Ein paar praxisnahe Beispiele, die Sie mit dem Telnet-Programm leicht nachvollziehen können, veranschaulichen die Kommunikation etwa beim Mail-Transfer.
| Die Themen dieses Abschnitts: | |
| E-Mail-Adressen SMTP: Mails senden |
POP3: Mails empfangen FTP: Dateitransfer |
Für E-Mail-Adressen werden Domain-Namen stets ohne die für Web-Server übliche Subdomain "www" benutzt. Eine typische Mail-Adresse zur Web-Seite www.firma.de lautet also z.B. postmaster@example.com. Dabei ist "postmaster" der lokale Benutzername, darauf folgt stets das Zeichen @ (AltGr-Q auf einer deutschen PC-Tastatur) und die Domain.
Bei den meisten Mail-Systemen wird bei Benutzernamen Groß- und Kleinschreibung nicht unterschieden. Statt "postmaster" darf man gewöhnlich also auch "Postmaster" oder "pOsTmAsTeR" schreiben. Dasselbe gilt - wie schon bei Web-Adressen - auch für Domain-Namen.
Mindestens zwei Benutzernamen sollte man für jede Domain einrichten: webmaster (die Person, die die Webseiten der Domain erstellt und pflegt) und postmaster (die Person, die das Mail-System der Domain überwacht). An diese zwei Benutzer sollte man Mails allerdings grundsätzlich nur mit administrativen Fragen senden, Produktanfragen oder gar Werbe-Mails wären hier völlig fehl am Platze.
Um Mails über Ihren Provider ans Internet zu senden, wird seit 1982 das Standard Mail Transfer Protocol (SMTP, RFC 2821) benutzt, das meist über den TCP/IP-Port 25 des Servers erreichbar ist. Wie bei HTTP wird hier wiederum an einem Telnet-Beispiel gezeigt, wie man ganz einfach eine kurze Text-Mail senden kann (Ihre Eingaben sind fett gedruckt):
c:>telnet pc1.example.com 25
220 Sambar SMTP server ready
helo pc2.example.com
250 provider.de Greetings, pc2.example.com
mail from:<alfred.meier@example.com>
250 sender ok
rcpt to:<info@example.com>
250 recipient ok
data
354 OK end with <CRLF>.<CRLF>
From: alfred.meier@example.com
To: info@example.com
Subject: Test-Mail
Dies ist eine kurze Beispiel-Nachricht
von Alfred Meier an Info.
.
250 Message accepted for delivery
quit
421 Goodbye
Folgende SMTP-Kommandos werden im obigen Beispiel benutzt:
Die Zahlencodes am Anfang jeder Antwortzeile (im obigen Dialog 220, 250, 354) erleichtern die Auswertung beim automatisierten Dialog eines "echten" Mail-Programms. Die Codes 2xx und 3xx bedeuten "OK", Werte ab 400 melden einen Fehler.
Einige wenige Provider versuchen, die Einlieferung von Massen-Mails (Bulk-Mails, meist unerwünschte Werbe-Mails) zu verhindern, indem sie deren Absendern das Leben mit einer Teergrube (englisch: tar pit) schwer machen. Dabei wird ab dem z.B. fünfzigsten RCPT-Kommando einer Verbindung die Server-Antwort künstlich um acht oder zehn Sekunden verzögert. Das Senden einer Mail an z.B. 10.000 Adressaten (oder auch 100 Mails an je 100 Adressaten) würde so fast einen ganzen Tag dauern. Der Haken dieser Mail-Bremse ist natürlich, dass sie auch anständige Absender betrifft, die beispielsweise Newsletter an Interessenten verschicken, die sich vorher selbst dafür registriert haben.
Die meisten SMTP-Server lassen das Senden von Mails nur zu, wenn man sich vorher eindeutig identifiziert hat, um Spam-, Junk- und Bulk-Mails zu verhindern - so nennt man unerwünschte Werbe-Mails. Das SMTP-Protokoll kennt in seiner ursprünglichen Form keine Authentifizierung mit Benutzername und Passwort; diese wurde später als SMTP-Option ergänzt (SMTP-AUTH, RFC 2554); hierbei wird statt Port 25 meist der so genannte Submission-Port 587 verwendet, die SMTP-Kommandos sind aber dieselben.
Alternativ erfolgt die Identifikation auch einfach durch die Einwahl beim gleichen Provider (PPP-Authentifizierung). Nur wer sich beispielsweise bei T-Online einwählt, kann auch den SMTP-Server von T-Online zum Senden von Mails benutzen, andernfalls erhält man die Fehlermeldung "Relaying denied" (Mail-Weiterleitung gesperrt).
Bei Benutzung eines anderen Providers wie z.B. 1und1 oder Strato ist oft auch eine vorherige POP3-Identifizierung ausreichend (SMTP after POP3). Dabei wird erst per POP3 abgefragt, ob neue Mails vorliegen, und erst dann werden Mails per SMTP gesendet. Leider lassen viele Mail-Programme wie etwa Outlook Express dieses Verfahren aber nur mit umständlichen Tricks zu, da sie normalerweise zuerst alle Mails senden (SMTP) und erst dann anliegende Mails abholen (POP3). Eine der wenigen Ausnahmen ist der NetMail-Server von Shamrock Software: Er sendet sofort nach dem POP3-Login Mails per SMTP und holt parallel dazu Mails via POP3 ab, was zu einer erheblichen Zeitersparnis führen kann.
Der Text der Nachricht kann als reiner ASCII-Text übertragen werden. Viele Mail-Programme benutzen jedoch den MIME-Standard (Multipurpose Internet Mail Extensions, RFC 1521), der auch Attachments zulässt, z.B. Binärdateien, Grafiken, HTML-Dateien und so weiter. Der Text kann "quoted-printable" codiert sein, so dass auch 8-Bit-Sonderzeichen über 7-Bit-Strecken übertragbar sind. Wenn Sie in Ihrem Mail-Programm mit "Eigenschaften" den Quelltext einer Nachricht ansehen, wird deutlich, wie das funktioniert: Im Mail-Header wird die Art der Codierung beschrieben, und vor hexadezimal codierten Umlauten oder auch vor "weichen" Zeilenumbrüchen steht ein Gleichheitszeichen als Kennung für ein Sonderzeichen, z.B. "=E4" für "ä".
Da Mail-Server eigentlich nur Text übertragen können, werden binäre Dateien üblicherweise im sogenannten Base64-Format übertragen. Dabei werden jeweils 6 Bits aus der Datei als ein ASCII-Zeichen übertragen. Für 6 Bits sind 64 unterschiedliche Zeichen nötig, diese sind:
| 0-25: 26-51: 52-63: |
ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789+/ |
Aus ursprünglich drei Bytes (24 Bit) entstehen so vier ASCII-Zeichen; die Base64-Codierung bläht die Daten also um 33 % auf. Am Schluss werden ggf. bis zu zwei Zeichen "=" angefügt, um zu erreichen, dass am Dateiende genau 24 Bit zur Decodierung übrig bleiben. Jede Base64-Zeile sollte maximal 76 Zeichen umfassen. Da E-Mails üblicherweise mit dem bereits gesicherten TCP/IP-Protokoll übertragen werden, enthält das Base64-Format keine zusätzliche Prüfsumme. Das untenstehende Javascript-basierte Formular erlaubt das Base64-Codieren und -Decodieren einer Textzeile.
An wen die Nachricht tatsächlich gesendet wird, wird bei SMTP allein durch das RCPT-Kommando bestimmt, nicht durch den Mail-Header, der vom Nutztext durch eine Leerzeile getrennt ist (RFC 2822). Ein Mail-Programm benutzt jedoch gewöhnlich die Angaben in den To-, Cc- und Bcc-Feldern in den Kopfdaten der Mail, um bei der Übertragung entsprechende RCPT-Kommandos zu erzeugen. Die Kopfdaten können unter anderem folgende Felder enthalten, wobei deren Reihenfolge nicht vorgeschrieben ist, und auch Groß- oder Kleinschreibung spielt keine Rolle:
Adressen in den Feldern From, To, Cc oder Bcc benutzen üblicherweise eines der folgenden Formate:
Die Variante 3 wird allerdings nicht empfohlen, auch wenn sie vom Netscape-Messenger (noch) benutzt wird. Angaben in Klammern sind Kommentare (z.B. eine Telefonnummer) und werden beim Mail-Senden ignoriert. Mehrere Mail-Adressen in einer Zeile können durch Kommata voneinander getrennt werden.
Um E-Mails von Ihrem Internet-Provider abzuholen, wird meist das POP3-Protokoll benutzt (Post Office Protocol Version 3, RFC 1725), das gewöhnlich auf dem Port 110 des Servers zur Verfügung steht.
Sie können zu Testzwecken auch hier das Telnet-Programm benutzen, um nachzusehen, ob bei Ihrem POP-Account Mails für Sie bereitliegen, ohne diese unbedingt gleich abholen oder löschen zu müssen. Stellen Sie dazu mit Telnet eine Verbindung zu Port 110 Ihres Providers her und geben Sie die POP-Kommandos manuell ein (Enter-Taste nach jeder Eingabezeile), zum Beispiel so:
c:>telnet pop.IhrProvider.de 110
+OK Sambar POP3 Server 4.3 ready
user IhrName
+OK Name accepted
pass IhrPasswort
+OK Mailbox ready.
list
+OK message list follows
.
quit
Statt list ist auch stat möglich. Falls Nachrichten da sind, können Sie sie nach list mit retr und der zugehörigen Nummer lesen und ggf. mit dele und der Nummer auch löschen, bevor Sie quit eingeben, also etwa so: retr 1 (Nachricht 1 wird geholt), dele 1 (Nachricht 1 wird gelöscht), quit (Verbindung wird beendet). Mit top x y kann man auch nur die ersten y Zeilen der Nachricht mit der Nummer x lesen, um beispielsweise zu prüfen, ob man eine sehr lange Mail wirklich abholen möchte. - Den Dialog, der hier mit dem Telnet-Programm manuell demonstriert wurde, macht ein "richtiges" Mail-Programm wie Outlook-Express, Echange oder Lotus-Notes ganz genauso, nur eben automatisch.
Wenn Sie eine eigene Domain wie IhreFirma.de besitzen, können Sie bei Ihrem Provider dafür gewöhnlich ein POP3-Sammelkonto einrichten, z.B. durch eine Umleitung von *@example.com an info@example.com. Dadurch ist es später möglich, alle E-Mails an Ihre Domain (unabhängig vom Namen vor dem Zeichen @) zeitsparend mit einem einzigen POP3-Anwahlvorgang vom Konto info abzuholen.
Um diese Mails dann z.B. in einem lokalen Netzwerk je nach dem Namen vor @ passend weiterzuverteilen, ist eine Gateway-Software nötig, z.B. fetchmail für Unix/Linux oder, für Windows, NetMail von Shamrock. Sie prüft die hinter To: und Cc: angegebenen Adressen und leitet die Mails dann allen zur lokalen Domain passenden Empfängern zu. Das funktioniert natürlich nicht bei Bcc-adressierten Mails (blind copy), da das Bcc-Feld der Mail schon beim Absender unterdrückt wird und das Weiterleiten im Internet allein durch das SMTP-Kommando "Rcpt to: <Adresse>" erfolgt.
Um bei einer BCC-adressierten Mail, bei der der Empfänger nicht hinter To: oder Cc: steht, trotzdem ermitteln zu können, für wen sie bestimmt ist, fügen einige Server eine zusätzliche Kopfzeile ein, die je nach Mail-System "envelope-to:", "x-envelope-to:", "delivered-to:" oder "x-pop3-rcpt:" heißen kann und die z.B. vom Mail-Programm NetMail auch ausgewertet wird.
Ähnlich fügen einige Mail-Systeme auch eine Zeile "Return-Path:" ein, in der das steht, was der Absender beim SMTP-Kommando "mail from:" übergeben hat. Solche Zusatzangaben, die nicht in den ursprünglich gesendeten Kopfdaten enthalten sind, nennt man auch "mail envelope", zu deutsch Briefumschlag.
Eine Alternative zu POP3 ist IMAP4 (Internet Message Access Protocol Version 4). IMAP4 kann zwar wie POP3 keine Mails senden, besitzt aber zahlreiche Kommandos, um mehrere Unter-Konten (mailboxes) erzeugen und verwalten zu können. Gegenüber POP3 ist es bisher allerdings weniger verbreitet und wird deshalb hier nur am Rande erwähnt.
Das File Transfer Protocol benutzt wie HTTP eine TCP/IP-Verbindung zur Dateiübertragung, beinhaltet jedoch mehr Möglichkeiten, um Verzeichnis-Listings zu übertragen und wird insbesondere oft eingesetzt, um erstellte HTML-Seiten und andere Dateien zu einem Web-Server zu übertragen.
Hierfür gibt es spezielle FTP-Programme, wie etwa das in Windows, Unix und Linux vorhandene FTP-Programm. Wenn Sie es starten, können Sie mit help eine Liste möglicher Befehle anzeigen und es später mit quit wieder beenden. Komfortablere wie das verbreitete WS_FTP bieten zum Teil auch die Möglichkeit, beim Senden großgeschriebene Dateinamen automatisch in die unter Unix üblichen Kleinbuchstaben umzuwandeln. In diesem Zusammenhang sei betont, dass es den meisten Web-Servern keineswegs egal ist, ob man eine Seiten-Adresse mit Web-Browser in Klein- oder Großbuchstaben eingibt: In Unix sind Test.htm und test.htm zwei unterschiedliche Dateien.
FTP-Programme besitzen gewöhnlich einen ASCII- und einen Binärmodus. Im ASCII-Modus wird nur Line-Feed (LF) als Zeilenumbruch-Zeichen übertragen, auch dann, wenn in der Quelldatei jede Zeile CR/LF endet; nur im Binär-Modus (sinnvoll für Grafik-, EXE- und ZIP-Dateien) bleibt die Datei unverändert.
Wer von einem FTP-Server eine Datei herunterlädt, kann das oft ohne vorherige Anmeldung tun und gibt als Pseudo-Benutzername einfach "anonymous" ein. Als Passwort ist es üblich, seine E-Mail-Adresse zu benutzen, aber das ist nicht zwingend erforderlich.
Eine Besonderheit von FTP ist es, dass nicht alles über eine einzige TCP-Verbindung abgewickelt wird: Normalerweise öffnet der FTP-Client einen Steuerkanal zum Host, und der Host-Rechner ruft sozusagen den Client auf einem anderen TCP-Port zurück, der dann für den eigentlichen Datentransfer benutzt wird. Da aber ankommende Verbindungen meist nicht möglich sind, wenn ein Firewall dazwischenliegt, hat man mit dem "passiven Transfer" (PASV) eine Variante geschaffen, bei der Steuer- und Datenkanal vom Client selbst geöffnet werden, so dass es hier nur abgehende Verbindungen gibt.
(Auf ein Telnet-Beispiel zur Demonstration von FTP-Server-Kommandos wie user, pass, port, list, retr, sto, quit usw. wird hier verzichtet, da wegen der Übertragung von Verzeichnislisten und Dateiinhalten über getrennte Ports die Benutzung eines FTP-Servers per Telnet-Programm nicht sinnvoll möglich ist.)
© Shamrock Software GmbH