SMTP-Auth: Unterschied zwischen den Versionen

Aus Foxwiki
Die Seite wurde neu angelegt: „'''SMTP-Auth''' (SMTP-Authentifizierung, auch als ASMTP bezeichnet) ist eine Erweiterung des ESMTP-Protokolls, die einem Mailserver eine Authentifizierung des Clients anhand seines Nutzernamens und Kennworts ermöglicht. Über einen SMTP-Auth-fähigen Server können normalerweise nur noch authentifizierte Absender Mails weiterleiten, was dazu beiträgt, den Missbrauch des Mailservers für Spam…“
 
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“
 
(23 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''SMTP-Auth''' (SMTP-Authentifizierung, auch als ASMTP bezeichnet) ist eine Erweiterung des [[Simple Mail Transfer Protocol#Extended SMTP|ESMTP]]-Protokolls, die einem [[Mailserver]] eine [[Authentifizierung]] des Clients anhand seines Nutzernamens und Kennworts ermöglicht.
'''SMTP-Auth''' (SMTP-Authentifizierung, auch als ASMTP bezeichnet) ist eine Erweiterung des [[Simple Mail Transfer Protocol#Extended SMTP|ESMTP]]-Protokolls, die einem [[Mailserver]] eine [[Authentifizierung]] des Clients anhand seines Nutzernamens und Kennworts ermöglicht.


Über einen SMTP-Auth-fähigen Server können normalerweise nur noch authentifizierte Absender Mails weiterleiten, was dazu beiträgt, den [[Missbrauch]] des Mailservers für [[Spam]] zu verhindern. Weiterleiten bezeichnet dabei das Versenden einer E-Mail an Empfänger außerhalb der Zuständigkeit des verwendeten Mailservers (siehe [[SMTP-Relay-Server]]). Gleichzeitig kann in den [[Log-Datei]]en nachvollzogen werden, wer einen [[SMTP-Relay-Server|SMTP-Server]] zum Mailrelay genutzt hat.
== Beschreibung ==
Über einen SMTP-Auth-fähigen Server können normalerweise nur noch authentifizierte Absender Mails weiterleiten, was dazu beiträgt, den [[Missbrauch]] des Mailservers für [[Spam]] zu verhindern.  
* Weiterleiten bezeichnet dabei das Versenden einer E-Mail an Empfänger außerhalb der Zuständigkeit des verwendeten Mailservers (siehe [[SMTP-Relay-Server]]).  
* Gleichzeitig kann in den [[Log-Datei]]en nachvollzogen werden, wer einen [[SMTP-Relay-Server|SMTP-Server]] zum Mailrelay genutzt hat.


Ursprünglich definierte RFC 2554 die ''SMTP Service Extension for Authentication'' als ein Profil vom ''[[Simple Authentication and Security Layer]]'' (SASL). Daraus ergaben sich verschiedene Authentifizierungsmechanismen.
Ursprünglich definierte RFC 2554 die ''SMTP Service Extension for Authentication'' als ein Profil vom ''[[Simple Authentication and Security Layer]]'' (SASL).  
* Daraus ergaben sich verschiedene Authentifizierungsmechanismen.


Laut RFC 4954 vom Juli 2007 enthält die Extension nur noch ein Profil vom SASL und gibt dessen Mechanismus PLAIN in Verbindung mit ''[[Transport Layer Security]]'' (TLS) zu ermöglichen vor. Die alternativen Mechanismen im SASL sind nur noch zusätzlich erlaubt, und der Server muss nun auf einer [[Verschlüsselung]] bestehen.
Laut RFC 4954 vom Juli 2007 enthält die Extension nur noch ein Profil vom SASL und gibt dessen Mechanismus PLAIN in Verbindung mit ''[[Transport Layer Security]]'' (TLS) zu ermöglichen vor.  
* Die alternativen Mechanismen im SASL sind nur noch zusätzlich erlaubt, und der Server muss nun auf einer [[Kryptografie]] bestehen.


Der Server bietet deshalb möglicherweise verschiedene Authentifizierungsmechanismen an, wovon sich der Client einen aussucht. Der Server stellt dem Client daraufhin je nach Mechanismus einen ''Challenge'' oder weist ihn zum Fortfahren an.
Der Server bietet deshalb möglicherweise verschiedene Authentifizierungsmechanismen an, wovon sich der Client einen aussucht.  
* Der Server stellt dem Client daraufhin je nach Mechanismus einen ''Challenge'' oder weist ihn zum Fortfahren an.


== Authentifizierungs-Verfahren ==
== Authentifizierungs-Verfahren ==
Je nach SMTP-Server und dessen Konfiguration werden verschiedene Verfahren durch den Server angeboten.
Je nach SMTP-Server und dessen Konfiguration werden verschiedene Verfahren durch den Server angeboten.


=== PLAIN ===
{| class="wikitable sortable"
Die PLAIN-Authentifizierung ist im RFC 4616 standardisiert. Hierbei wird Benutzername (zur Autorisierung), Benutzername (zur Authentifizierung) und Passwort unverschlüsselt übertragen. Die drei Zeichenketten werden in einer Zeichenkette zusammengefasst und [[Base64]]-kodiert.
|-
 
! Aufgabe !! Befehl
=== LOGIN ===
|-
Bei der LOGIN-Authentifizierung wird wie bei der PLAIN-Authentifizierung der Benutzername und das Passwort unverschlüsselt [[Base64]]-kodiert übertragen. Im Unterschied zur PLAIN-Authentifizierung werden die beiden Zeichenketten in zwei Schritten übertragen.
| PLAIN || Die PLAIN-Authentifizierung ist im RFC 4616 standardisiert.  
 
* Hierbei wird Benutzername (zur Autorisierung), Benutzername (zur Authentifizierung) und Passwort unverschlüsselt übertragen.  
=== CRAM-MD5 ===
* Die drei Zeichenketten werden in einer Zeichenkette zusammengefasst und [[Base64]]-kodiert.
Die [[CRAM-MD5]]-Authentifizierung ist im RFC 2195 standardisiert.
|-
 
| LOGIN || Bei der LOGIN-Authentifizierung wird wie bei der PLAIN-Authentifizierung der Benutzername und das Passwort unverschlüsselt [[Base64]]-kodiert übertragen.  
=== SCRAM-SHA-1 ===
* Im Unterschied zur PLAIN-Authentifizierung werden die beiden Zeichenketten in zwei Schritten übertragen.
Die [[SCRAM-SHA-1]]-Authentifizierung ist im RFC 5802 standardisiert.
|-
| CRAM-MD5 || Die [[CRAM-MD5]]-Authentifizierung ist im RFC 2195 standardisiert.
|-
| SCRAM-SHA-1 || Die [[SCRAM-SHA-1]]-Authentifizierung ist im RFC 5802 standardisiert.
|-
| NTLM || Die Authentifizierung erfolgt über [[NTLM]].
|}
== Installation ==
== Aufruf ==
=== Parameter ===
=== Optionen ===
=== Umgebung ===
=== Rückgabewert ===


=== NTLM ===
== Konfiguration ==
Die Authentifizierung erfolgt über [[NTLM]].
=== Dateien ===


== Beispiel ==
== Anwendung ==
Die folgende ESMTP-Session in Klartext und mit [[Verschlüsselung|unverschlüsselten]] LOGIN-Verfahren demonstriert die Authentifizierung. Bei produktiven Mailservern sollte die gezeigte Übertragung sensibler Daten in Klartext nicht angewendet werden und beispielsweise vor der Authentifizierung mittels [[STARTTLS]] auf eine verschlüsselte Kommunikation gewechselt werden.
Die folgende ESMTP-Session in Klartext und mit [[Kryptografie|unverschlüsselten]] LOGIN-Verfahren demonstriert die Authentifizierung.  
* Bei produktiven Mailservern sollte die gezeigte Übertragung sensibler Daten in Klartext nicht angewandt werden und beispielsweise vor der Authentifizierung mittels [[STARTTLS]] auf eine verschlüsselte Kommunikation gewechselt werden.


{|
{|
Zeile 69: Zeile 88:
|}
|}


== Siehe auch ==
== Sicherheit ==
* [[SMTP-After-POP]]
== Dokumentation ==
 
=== RFC ===
# RFC 1321 – The MD5 Message Digest Algorithm
# RFC 2104 – HMAC: Keyed-Hashing for Message Authentication
# RFC 2595 – Using TLS with IMAP, POP3 and ACAP
 
=== Man-Page ===
=== Info-Pages ===
=== Siehe auch ===
# [[SMTP-After-POP]]
 
== Links ==
=== Projekt-Homepage ===
=== Weblinks ===
 


== Weblinks ==
* RFC 1321 – The MD5 Message Digest Algorithm
* RFC 2104 – HMAC: Keyed-Hashing for Message Authentication
* RFC 2595 – Using TLS with IMAP, POP3 and ACAP


{{SORTIERUNG:Smtp Auth}}
[[Kategorie:SMTP]]
[[Kategorie:Internet-E-Mail-Protokoll]]
[[Kategorie:Postfix/Sicherheit]]

Aktuelle Version vom 12. November 2024, 18:45 Uhr

SMTP-Auth (SMTP-Authentifizierung, auch als ASMTP bezeichnet) ist eine Erweiterung des ESMTP-Protokolls, die einem Mailserver eine Authentifizierung des Clients anhand seines Nutzernamens und Kennworts ermöglicht.

Beschreibung

Über einen SMTP-Auth-fähigen Server können normalerweise nur noch authentifizierte Absender Mails weiterleiten, was dazu beiträgt, den Missbrauch des Mailservers für Spam zu verhindern.

  • Weiterleiten bezeichnet dabei das Versenden einer E-Mail an Empfänger außerhalb der Zuständigkeit des verwendeten Mailservers (siehe SMTP-Relay-Server).
  • Gleichzeitig kann in den Log-Dateien nachvollzogen werden, wer einen SMTP-Server zum Mailrelay genutzt hat.

Ursprünglich definierte RFC 2554 die SMTP Service Extension for Authentication als ein Profil vom Simple Authentication and Security Layer (SASL).

  • Daraus ergaben sich verschiedene Authentifizierungsmechanismen.

Laut RFC 4954 vom Juli 2007 enthält die Extension nur noch ein Profil vom SASL und gibt dessen Mechanismus PLAIN in Verbindung mit Transport Layer Security (TLS) zu ermöglichen vor.

  • Die alternativen Mechanismen im SASL sind nur noch zusätzlich erlaubt, und der Server muss nun auf einer Kryptografie bestehen.

Der Server bietet deshalb möglicherweise verschiedene Authentifizierungsmechanismen an, wovon sich der Client einen aussucht.

  • Der Server stellt dem Client daraufhin je nach Mechanismus einen Challenge oder weist ihn zum Fortfahren an.

Authentifizierungs-Verfahren

Je nach SMTP-Server und dessen Konfiguration werden verschiedene Verfahren durch den Server angeboten.

Aufgabe Befehl
PLAIN Die PLAIN-Authentifizierung ist im RFC 4616 standardisiert.
  • Hierbei wird Benutzername (zur Autorisierung), Benutzername (zur Authentifizierung) und Passwort unverschlüsselt übertragen.
  • Die drei Zeichenketten werden in einer Zeichenkette zusammengefasst und Base64-kodiert.
LOGIN Bei der LOGIN-Authentifizierung wird wie bei der PLAIN-Authentifizierung der Benutzername und das Passwort unverschlüsselt Base64-kodiert übertragen.
  • Im Unterschied zur PLAIN-Authentifizierung werden die beiden Zeichenketten in zwei Schritten übertragen.
CRAM-MD5 Die CRAM-MD5-Authentifizierung ist im RFC 2195 standardisiert.
SCRAM-SHA-1 Die SCRAM-SHA-1-Authentifizierung ist im RFC 5802 standardisiert.
NTLM Die Authentifizierung erfolgt über NTLM.

Installation

Aufruf

Parameter

Optionen

Umgebung

Rückgabewert

Konfiguration

Dateien

Anwendung

Die folgende ESMTP-Session in Klartext und mit unverschlüsselten LOGIN-Verfahren demonstriert die Authentifizierung.

  • Bei produktiven Mailservern sollte die gezeigte Übertragung sensibler Daten in Klartext nicht angewandt werden und beispielsweise vor der Authentifizierung mittels STARTTLS auf eine verschlüsselte Kommunikation gewechselt werden.
> 220 mail.example.org ESMTP
< EHLO example.net
> 250-example.org Hello example.net
> 250 AUTH CRAM-MD5 LOGIN PLAIN
< AUTH LOGIN
> 334 VXNlcm5hbWU6
< aGFucw==
> 334 UGFzc3dvcmQ6
< c2Nobml0emVsbWl0a2FydG9mZmVsc2FsYXQ=
> 235 ok
< MAIL FROM:<hans@example.net>
> 250 ok
< RCPT TO:<fritz@example.org>
> 250 ok
< DATA
> 354 Go ahead.
< From:<hans@example.net>
< To:<fritz@example.org>
< Subject: Hallo
<
< Hallo Fritz.
< .
> 250 Mail delivered.
< QUIT
Klartext (base64 decoded)




334 Username:
hans
334 Password:
schnitzelmitkartoffelsalat

Sicherheit

Dokumentation

RFC

  1. RFC 1321 – The MD5 Message Digest Algorithm
  2. RFC 2104 – HMAC: Keyed-Hashing for Message Authentication
  3. RFC 2595 – Using TLS with IMAP, POP3 and ACAP

Man-Page

Info-Pages

Siehe auch

  1. SMTP-After-POP

Links

Projekt-Homepage

Weblinks