Wie E-Mail technisch funktioniert
Grundsätzlich muss man unterscheiden zwischen einem authentifizierten und einem unauthentifizierten E-Mailtransport. Bei authentifizierten E-Mailtransport wird ein Name und Passwort verlangt und im Zuge des E-Mailtransports übertragen. Bei einem unauthentifizierten E-Mailtransport wird dieses nicht verlangt. Hintergrund für einen authentifizierten E-Mailtransport ist sicher die Idee das Personen, die eine E-Mail versenden wollen, sich bei der jeweiligen Institution über die sie senden sich quasi "anmelden" um einen Mißbrauch vorzubeugen. Die Institution verifiziert dann das bei dieser passende Passwort und sendet dann die E-Mail weiter. Eine Authentifizierung zwischen weltweit kooperierenden E-Mailservern ist nicht möglich, da sonst z.B. jeder der Server einen Namen und ein Passwort bei dem Zielserver benötigen würde - und das weltweit.
Es wird in der Literatur wie folgt unterschieden:
MUA (MailUserAgent), also einen E-Mailclient auf einem persönlichen Computer
MTA (MailTransferAgent) also ein Programm auf einem E-Mailserver der die E-Mail zum Zielserver weiterleitet
MDA (MailDeliveryAgent) also ein Postfachserverprogramm auf einem Server, der dann wiederum die E-Mail einem MUA bereitstellt.
Hierbei wird ein Unterschied unterstellt zwischen einem persönlichen Computer (PC) auf dem ein oder mehrere Personen nacheinander arbeiten und einem Server auf dem nur ein Administrator verwaltet.
Der E-Mailtransfer verläuft zwischen MTAs und MTA zu MDA (also Server zu Serverkommunikation) immer unauthentifiziert, zwischen MUA und MTA bzw. MDA (also immer mit einem PC) immer authentifiziert.
Hinweis: Ob eine Authentifizierung eines MUA bei einem MTA erforderlich ist und wie stark diese ist (beispielsweise Prüfung von Absendeadresse) obliegt der Server-Admiinstration. Wenn diese nicht oder sehr gering vorhanden ist, spricht man von einem "offenen Relay" welches, zum Beispiel Spam, ungehindert in die Welt sendet.
Hinweis: Ein Programm auf einem Server kann durchaus auch als MUA handeln, d.h. die E-Mail mittels Name und Passwort einem MTA übertragen.
Ein E-Mailtransfer benötigt quasi eine Art Türe auf dem Quell- und Zielcomputer. Dieser Port ist verbunden mit einem jeweils definiertem Protokoll. Dabei sind Ports unter 1024 Systemports, und ab 1024 Userports. Details siehe [[https://de.wikipedia.org/wiki/Port_(Protokoll)]]
Zum Versenden von E-Mails wird unterschieden zwischen folgenden Möglichkeiten:
zum Empfangen von E-Mails
Alle Ports außer dem Port 25 verlangen i.d.R. eine Authentifizierung!
Details zum Aufbau einer E-Mail siehe Aufbau einer E-Mail.
Hier nun die technischen Details des SMTP (Simple Mail Transfer Protocol)
1. CONNECT Hier tauschen die Computer die IP-Adressen aus
2. HELO / EHLO Hier meldet sich der sendende Computer i.d.R. mit seinem vollständigen Namen (FQDN) an. Der Unterschied zwischen HELO und EHLO ist, dass bei einem EHLO der Server zurück meldet, welche Möglichkeiten bei diesem vorhanden sind. Also beispielsweise STARTTLS oder anderes.
3. MAIL FROM: Hier teilt der sendende Computer mit, mit welcher E-Mailadresse gesendet wird. Das ist Teil des sogenannten "Envelope"
4. RCPT TO: Hier teilt der sendende Computer mit, an welche E-Mailadresse er senden möchte Das ist Teil der sogenannten "Envelope"
5. DATA Hier folgt nun die eigentlich E-Mail inkl. des Headers
Beispiel:
# telnet mail-relay150 25
Trying 2001:41b8:83f:1611::150...
Connected to mail-relay150.hrz.tu-darmstadt.de.
>> Escape character is '^]'.
>> 220 mail-relay150.hrz.tu-darmstadt.de ESMTP Postfix
<< EHLO www-cgi03
>> 250-mail-relay150.hrz.tu-darmstadt.de
>> 250-SIZE 104857600
>> 250-STARTTLS
<< MAIL FROM:<dirk.weikard@tu-darmstadt.de>
>> 250 2.1.0 Ok
<< RCPT TO:<service@hrz.tu-darmstadt.de>
>> 250 2.1.5 Ok
<< DATA
>> 354 End data with <CR><LF>.<CR><LF>
Nun kommt der E-Mailheader und die E-Mail-Nachricht
Beispiel einer Fehlermeldung
<< MAIL FROM:<dirk.weikard@tu-darmstadt.de>
>> 530-5.7.0 Must issue a STARTTLS command first
>> 530 5.7.0 Fuer weitere Hilfe wenden Sie sich bitte an ...
Der Transfer kann jederzeit beendet werden
<< QUIT
>> 221 2.0.0 Bye
>> Connection closed by foreign host.
Also kommt vom dem MTA ein Code außer 2.. so ist dieses ein Fehler. Die Fehlerbeschreibung liefert dann der MTA anschließend.
Häufiger Fehler:
"Must issue a STARTTLS command first" - also ist STARTTLS nach dem HELO/ELHO nicht benutzt worden - muss man bim Senden an der TU Darmstadt zwischen Servern aktivieren
(im sendenden Postfix beispielsweise durch "smtp_tls_security_level = encrypt")
Hinweise:
Ein E-Mailclient (MUA) sendet in gleicher Weise die E-Mails. Hierbei wird automatisch vom MUA der Envelope (MAIL FROM/RCPT TO) aus der E-Mail entsprechend gesetzt.
Beim Senden an Empfangsadressen im sogenannten BCC (BlindCarbonCopy) werden diese Empfangsadressen in den Envelope gesetzt (RCPT TO) aber in dem E-Mailheader weggelassen.
Wenn an mehr als eine Adresse gesendet wird, kann der sendende Computer diese entweder einzeln über tragen (also jeweils mit einem "RCPT TO" nur) oder gesamt (mehrere "RCPT TO" hintereinander). Dabei hängt es beim weiteren Transport ab, wie der MTA die E-Mails letztlich in passende Empfangsadressen-Pakete unterteilt.
Scheitert die Zustellung an eine Ziel-E-Mailadresse im Envelope (RCPT TO) so wird eine entsprechende Fehlermeldung (i.d.R.) an die Absendende E-Mailadresse im Envelope (MAIL FROM) gesendet. Die Adressen im E-Mailheader werden beim weiteren Transfer nicht berücksichtigt.
Der Transport von dem E-Mailtransfer kann auch zwischen MTAs verschlüsselt werden. Hierbei muss darauf geachtet werden, dass der sendende wie der empfangende Server eine Verschlüsselung zuläßt oder sie gar erzwingt. Und natürlich müssen beide Seiten die Art der Verschlüsselung auch gleichermaßen unterstützen (SSL- bzw. TLS-Version). Derzeit (Stand 10/2021) wird TLS1.2 aufwärts für sicher empfunden.
Beispiel Postfix:
Sendende Server:
smtp_tls_security_level = encrypt
Empfangender Server:
smtpd_tls_security_level = encrypt
Der E-Mailclient (MUA) übernimmt vielfältige Aufgaben:
Automatische Benachrichtungen für die sendende Person die diese beim Erstellen der E-Mail einstellen kann, wie dem "Delivery Status Notification (DSN)" ("E-Mail wurde in das Postfahc geliefert") und dem "Message Disposition Notification (MDN)" ("E-Mail wurde von der Person gelesen") sind zwar interessant, aber wenig hilfreich: Denn ersteres (DSN) wird nicht von jedem Server unterstützt, und letzteres (MDN) kann explizit von der empfangenden Person unterdrückt werden und kann von dieser auch als übergriffig empfunden werden.
Dies alles beschriebt die üblichen Vorgehensweisen eines MUA, MTA, MDA. Aber diese lassen sich in vielfältig verändern.