Internet-Grundlagen

Dieser 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.

WWWDateitransfer mit HTTP

Das 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

Web-Adressen

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:
http://www.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/1.0

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.

HTTP/1.1

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.

SSL, DES und https-Seiten

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.

Server-Log

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.

RFC-Standards

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.


SMTP, POP3, FTP

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

E-Mail-Adressen

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.

SMTP: Mails senden

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

SMTP-Kommandos

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.

SMTP-Authentifizierung

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.

MIME und Base64

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.

Mail-Kopfdaten

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:

  1. hans.meier@example.com
  2. <hans.meier@example.com>
  3. Hans Meier <hans.meier@example.come>
  4. "Hans Meier" <hans.meier@example.com>
  5. "Hans Meier" <hans.meier@example.com> (040 987654)

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.

POP3: Mails empfangen

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.

POP3-Kommandos

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.

POP3-Sammelkonto und Weiterverteilung

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.

Mail-Envelope

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.

Alternative zu POP3: IMAP4

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.

FTP: Dateitransfer

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