Fragen zu SMTP-AUTH
Gerson Kurz
ich hoffe ich bin hier richtig. Ich möchte für meinen POP3/SMTP-Server
(siehe http://www.p-nand-q.com/shicks.htm) jetzt auch SMTP AUTH
implementieren. Ich habe RFC2554 studiert, aber so richtig
funktioniert das alles noch nicht. Scheinbar unterstützt jeder Client
seinen eigenen AUTH-Dialekt und verweigert jede andere Antwort. Das
RFC hat auch lücken, z.B. geht denke ich nicht klar hervor, was ich
antworten soll, wenn AUTH fehlschlägt. (Es gibt temporary auth
failure, aber ein falscher login ist ja nicht temporary); oder, das
RFC sagt nichts über die AUTH-Mechanismen im einzelnen und die
tatsächlich in der Praxis vorkommenden.
Also. Ich gebe bei EHLO als Server Extension AUTH mit. Im RFC wird als
Beispiel
250 AUTH CRAM-MD5 DIGEST-MD5
zurückgegeben. Ich habe aber gelesen, daß es broken Reader gibt, die
250 AUTH=LOGIN
erwarten; und richtig, wenn ich das nicht hinschreibe, interessieren
sich weder Mozilla noch Outlook ("Normal" plus OE) für SMTP AUTH. Dass
es ueberhaupt AUTH=LOGIN gibt habe ich nach ewigem herumgegoogle
herausgefunden. CRAM-MD5 macht scheinbar überhaupt nur die python
smtplib und ein paar Unix-Reader. Es gibt im Netz hinweise, das die
genannten beiden Clients SMTP AUTH nicht unterstützen, aber die
Hinweise beziehen sich auf jeweils alte Versionen der Clients (NS4.7,
OE4.x) - scheinbar gilt das auch noch für die aktuellen Clients ?
OK, zu den Details. SMTP AUTH bei Kommunikation über die smtplib:
BEGIN of SMTP conversation with ('127.0.0.1', 4159)
WRITE:220 SHICKS! Service ready
READ:ehlo null
WRITE:250-Shicks! 0.6 ready.
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-AUTH LOGIN CRAM-MD5 PLAIN
250-SIZE
250-VRFY
250 HELP
READ:AUTH CRAM-MD5
WRITE:334 MTgyOC4yMDE2LjgyNS44ODA4NDE0MzNAbnVsbC44MTg3Njgw
READ:Z2Vyc29uIDIyNTBhNjQyZDg4MGY1ZGI0N2QxOTU3MDk2NGQ1NzY0
WRITE:235 Authentication successful.
READ:mail FROM:<gerson.kurz@localhost> size=92
WRITE:250 OK
READ:rcpt TO:<gerson.kurz@localhost>
WRITE:250 OK
READ:data
WRITE:354 Start mail input; end with <CRLF>.<CRLF>
...
WRITE:250 OK
READ:quit
WRITE:221 SHICKS! Service closing transmission channel
END of SMTP conversation with ('127.0.0.1', 4159)
Genau so hätte ich das eigentlich erwartet. Jetzt das ganze über
Mozilla (0.9.9):
BEGIN of SMTP conversation with ('127.0.0.1', 4187)
WRITE:220 SHICKS! Service ready
READ:EHLO localhost
WRITE:250-Shicks! 0.6 ready.
250-AUTH=LOGIN CRAM-MD5
250-AUTH LOGIN CRAM-MD5
250-SIZE
250-VRFY
250 HELP
READ:AUTH LOGIN Z2Vyc29u
WRITE:334 OK
READ:ZGVwcA==
WRITE:235 Authentication successful.
READ:MAIL FROM:<gerson.kurz@localhost>
WRITE:250 OK
READ:RCPT TO:<gerson.kurz@localhost>
WRITE:250 OK
READ:DATA
WRITE:354 Start mail input; end with <CRLF>.<CRLF>
...
WRITE:250 OK
END of SMTP conversation with ('127.0.0.1', 4187)
Das ist schon ein bisserl unerwartet; auf
534 Authentication mechanism is too weak
reagiert Mozilla scheinbar überhaupt nicht, und wenn ich nur
"CRAM-MD5" angebe, macht Mozilla gar kein AUTH. Soviel zu
Standardtreue von Mozilla :(
Nun zu OE, da komme ich gar nicht weiter:
BEGIN of SMTP conversation with ('127.0.0.1', 4199)
ipaddress '127.0.0.1' as long = 2130706433
Connection is from localhost, skipping relay checks.
WRITE:220 SHICKS! Service ready
READ:EHLO null
sender is 'null'
WRITE:250-Shicks! 0.6 ready.
250-AUTH=LOGIN CRAM-MD5
250-AUTH LOGIN CRAM-MD5
250-SIZE
250-VRFY
250 HELP
READ:AUTH LOGIN
An dieser Stelle kann ich scheinbar Antworten was auch immer ich will,
OE schickt als nächstes grundsätzlich IMMER
READ:MAIL FROM: <gerson.kurz@localhost>
Spitze! Gibt es SMTP AUTH bei OE überhaupt? Was bringt SMTP AUTH, wenn
es von OE nicht unterstützt wird? Wie kann ich, wenn der Client OE
ist, "ein bisserl auth" realisieren (ausser durch
POP3-LOGIN-VOR-SMTP). Und kann bitte jemand den RFC neu schreiben, so
dass er eindeutiger wird?...
Ciao, Gerson
Markus Weber
"Gerson Kurz" <moc.q-...@p-nand-q.com> schrieb im Newsbeitrag >
> Spitze! Gibt es SMTP AUTH bei OE überhaupt? Was bringt SMTP AUTH, wenn
> es von OE nicht unterstützt wird? Wie kann ich, wenn der Client OE
> ist, "ein bisserl auth" realisieren (ausser durch
> POP3-LOGIN-VOR-SMTP). Und kann bitte jemand den RFC neu schreiben, so
> dass er eindeutiger wird?...
Selbstverstaendlich unterstuetzt OE SMTP_AUTH !
In den Eigenschaften von deinem Mailkonto gibt es die Option:
"Server erfordert Authentifizierung"
Das waer dann "AUTH LOGIN" und PLAIN.
Aber OE ist da ne Extrawurst, deswegen gibt es:
AUTH LOGIN und AUTH=LOGIN.
Um auch OE Clients Zugang gewaehren zu koennen
musst du beim uebersetzen der Quellen im configure-script
noch "enable-login" angeben.
Mit den RPM's von RedHat geht es auf alle Faelle.
Gerson Kurz
<li...@leute.server.de> wrote:
>Selbstverstaendlich unterstuetzt OE SMTP_AUTH !
>In den Eigenschaften von deinem Mailkonto gibt es die Option:
>"Server erfordert Authentifizierung"
>Das waer dann "AUTH LOGIN" und PLAIN.
>Aber OE ist da ne Extrawurst, deswegen gibt es:
>AUTH LOGIN und AUTH=LOGIN.
>Um auch OE Clients Zugang gewaehren zu koennen
>musst du beim uebersetzen der Quellen im configure-script
>noch "enable-login" angeben.
>Mit den RPM's von RedHat geht es auf alle Faelle.
Hallo Markus,
danke für die Antwort.
Es geht um meinen eigenen selbstgeschriebenen Server (da gibt es also
auch keine RPMs für ;), ich habe also die Frage: Wie schaut so eine
SMTP-AUTH Kommunikation mit OE korrekt aus. Ohne "Server erfordert
Authentifizierung", macht OE ja gar kein "AUTH LOGIN"; meine Frage ist
also, wie "AUTH LOGIN" reagieren soll.
Mir wäre sehr geholfen, wenn hier jemand ein SMTP-Protokoll einer
erfolgreichen SMTP-AUTH Sitzung posten/schicken könnte. CRAM-MD5 kann
OE nicht, oder?
Matthias Andree
> smtplib und ein paar Unix-Reader. Es gibt im Netz hinweise, das die
> genannten beiden Clients SMTP AUTH nicht unterstützen, aber die
> Hinweise beziehen sich auf jeweils alte Versionen der Clients (NS4.7,
> OE4.x) - scheinbar gilt das auch noch für die aktuellen Clients ?
OE 4.x hält sich nicht an den Standard. Die Postfix-Mailingliste
(msgs.securepoint.com hat eines der Archive davon) ist voll von
Diskussionen darüber.
--
Matthias Andree
Jakob Hirsch
Hi,
> RFC hat auch lücken, z.B. geht denke ich nicht klar hervor, was ich
> antworten soll, wenn AUTH fehlschlägt. (Es gibt temporary auth
> failure, aber ein falscher login ist ja nicht temporary); oder, das
4. The AUTH command
[...]
AUTH command with a 501 reply. If the server rejects the
authentication data, it SHOULD reject the AUTH command with a
535 reply unless a more specific error code, such as one listed
in section 6, is appropriate. Should the client successfully
Was ist denn daran unklar?
> Also. Ich gebe bei EHLO als Server Extension AUTH mit. Im RFC wird als
> Beispiel
>
> 250 AUTH CRAM-MD5 DIGEST-MD5
Ich wüßte keinen Client, der DIGEST-MD5 benutzt. CRAM-MD5 wird zumindest
von Eudora benutzt. Outlook Express kann nur AUTH LOGIN, Netscape AUTH
PLAIN.
> 250 AUTH=LOGIN
Ja, AFAIK ältere (<5) Versionen von OE. Wie es bei Outlook aussieht,
weiß ich nicht.
> smtplib und ein paar Unix-Reader. Es gibt im Netz hinweise, das die
> genannten beiden Clients SMTP AUTH nicht unterstützen, aber die
> Hinweise beziehen sich auf jeweils alte Versionen der Clients (NS4.7,
> OE4.x) - scheinbar gilt das auch noch für die aktuellen Clients ?
Netscape unterstützt definitiv SMTP AUTH, ich weiß aber nicht, seit
welcher Version. Die 4.7 aber auf jeden Fall.
> Genau so hätte ich das eigentlich erwartet. Jetzt das ganze über
> Mozilla (0.9.9):
>
> READ:ZGVwcA==
Nana. :)
> 534 Authentication mechanism is too weak
>
> reagiert Mozilla scheinbar überhaupt nicht, und wenn ich nur
Wie reagiert er denn und wie sollte er deiner Meinung nach reagieren?
> "CRAM-MD5" angebe, macht Mozilla gar kein AUTH. Soviel zu
> Standardtreue von Mozilla :(
Wird CRAM-MD5 vom RFC zwingend verlangt? Ich glaube nicht. Dass ein
Client sich nur mit den Verfahren authenfiziert, die er auch beherrscht,
is ja klar.
> An dieser Stelle kann ich scheinbar Antworten was auch immer ich will,
> OE schickt als nächstes grundsätzlich IMMER
OE erwartet "Username:" und "Passwort:". Sieht dann ungefähr so aus:
SMTP: 19:08:23 [rx] 220 mail2.netlight.de ESMTP Exim 3.35 #2 Wed, 17 Apr
2002 19:08:24 +0200
SMTP: 19:08:23 [tx] EHLO ws
SMTP: 19:08:23 [rx] 250-mail2.netlight.de Hello
pd95478f6.dip.t-dialin.net [217.84.120.246]
SMTP: 19:08:23 [rx] 250-SIZE 33554432
SMTP: 19:08:23 [rx] 250-ETRN
SMTP: 19:08:23 [rx] 250-PIPELINING
SMTP: 19:08:23 [rx] 250-AUTH CRAM-MD5 LOGIN PLAIN
SMTP: 19:08:23 [rx] 250 HELP
SMTP: 19:08:23 [tx] AUTH LOGIN
SMTP: 19:08:23 [rx] 334 VXNlcm5hbWU6
SMTP: 19:08:23 [tx] xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
SMTP: 19:08:23 [rx] 334 UGFzc3dvcmQ6
SMTP: 19:08:23 [tx] xxxxxxxxxxxxxxxxx
SMTP: 19:08:24 [rx] 235 Authentication succeeded
> Spitze! Gibt es SMTP AUTH bei OE überhaupt? Was bringt SMTP AUTH, wenn
Klar, man muß es aber explizit aktivieren, "Server erfordert
Authentifizierung" oder so. Finde ich auch sinnvoller als Netscape, der
fragt grundsätzlich nach Benutzerdaten, wenn der Server AUTH anbietet.
--
regards, Jakob
ICQ# 78958588
Joern Weber
moc.q-...@p-nand-q.com (Gerson Kurz) schrieb/wrote:
Hi
> ich hoffe ich bin hier richtig.
Ja.
> Ich möchte für meinen POP3/SMTP-Server
> (siehe http://www.p-nand-q.com/shicks.htm) jetzt auch SMTP AUTH
> implementieren.
Kenne ich zwar nicht, aber SMTP-Auth habe ich schon mal implementiert.
> Ich habe RFC2554 studiert, aber so richtig
> funktioniert das alles noch nicht.
Das kann ich mir gut vorstellen. Dir fehlen sicher dann noch ein Dutzend
weiterer RFC's. Stichworte zum googlen:
SASL
CRAM
HMAC
MD5
SHA-1
Der SASL PLAIN Mechanismus ist im TLS-RFC versteckt. Auch in den LDAP,IMAP
und POP3 RFC's finden sich Definitionen zu den einzelnen SASL Mechanismen.
> Scheinbar unterstützt jeder Client seinen eigenen AUTH-Dialekt
> und verweigert jede andere Antwort.
Nein. Es gibt eine offizielle und eine properitäre Spielart. Die
properitäre Spielart stammt noch aus der Zeit vor SASL und ist eine
private Erweiterung von ESMTP. Erst der SASL RFC standardisiert die
unterschiedlichen Login-Methoden in einem einheitlichen Verfahren.
> Das RFC hat auch lücken,
Nein. RFC 2224 hat diverse direkte und indirekte Bezüge zu diversen
anderen RFC's.
> Also. Ich gebe bei EHLO als Server Extension AUTH mit. Im RFC wird als
> Beispiel
> 250 AUTH CRAM-MD5 DIGEST-MD5
> zurückgegeben. Ich habe aber gelesen, daß es broken Reader gibt, die
> 250 AUTH=LOGIN
> erwarten;
Broken sind die nicht und veraltet. Und deshalb solltest Du beide
Varianten angeben.
> und richtig, wenn ich das nicht hinschreibe, interessieren
> sich weder Mozilla noch Outlook ("Normal" plus OE) für SMTP AUTH.
Das ist versionsabhängig. In den aktuellen Versionen ist das IMHO gefixt.
> CRAM-MD5 macht scheinbar überhaupt nur die python
> smtplib und ein paar Unix-Reader.
Nein. Der Hamster kann z.B. damit auch umgehen. Allerdings sind AUTH
Loginmechanismen nicht mehr Stand der Technik. Es gibt mit SSL/TLS ein
Verfahren, um nicht nur die Accountdaten zu schützen, sondern die gesamte
Kommunikation zwischen Server und Client. Auch wenn der letzte TLS-RFC vom
Februar diesen Jahres noch den SALS Mechanismus PLAIN spezifiziert gibt es
inzwischen besseres, und zwar SSL mit Client-Zertifikate. Dann bleibt also
letztendlich langfristig von den AUTH-Mechanismen nur noch EXTERNAL aus
Kompatibilitätsgründen übrig. Das Problem bei der Entwicklung der
Login-Methoden sind aber letztendlich die Betreiber von grossen
Mailservern. Einige bieten inzwischen AUTH an, wenige auch SSL, so gut wie
keiner SSL mit Client-Zertifikate, aber bis ein Zustand erreicht wird, bei
dem AUTH überflüssig wird, dürften noch Jahrzehnte vergehen. Auf der
Clientseite hingegen ist die Verfügbarkeit kein Problem, da man auf jeden
Windows- und Unix-Rechner jeden Reader mit einem Zusatztool (stunnel) auf
SSL nachrüsten kann. Selbst Client-Zertifikate sind damit möglich.
> Es gibt im Netz hinweise, das die
> genannten beiden Clients SMTP AUTH nicht unterstützen, aber die
> Hinweise beziehen sich auf jeweils alte Versionen der Clients (NS4.7,
> OE4.x) - scheinbar gilt das auch noch für die aktuellen Clients ?
Nein.
> Jetzt das ganze über Mozilla (0.9.9):
> WRITE:250-Shicks! 0.6 ready.
> 250-AUTH=LOGIN CRAM-MD5
> 250-AUTH LOGIN CRAM-MD5
[...]
> READ:AUTH LOGIN Z2Vyc29u
> WRITE:334 OK
> READ:ZGVwcA==
> WRITE:235 Authentication successful.
> Das ist schon ein bisserl unerwartet;
Nein, völlig korrekt, der Client darf einen der angebotenen
SASL-Mechanismen nach seinem belieben auswählen. Er will ja schliesslich
die Accountdaten schützen nicht der Server, so kann er auch im Rahmen des
Angebotenen entscheiden wie stark er das möchte. Will der Server die
Login-Daten selber schützen darf er nur sichere Mechanismen anbieten.
> auf
> 534 Authentication mechanism is too weak
> reagiert Mozilla scheinbar überhaupt nicht, und wenn ich nur
> "CRAM-MD5" angebe, macht Mozilla gar kein AUTH. Soviel zu
> Standardtreue von Mozilla :(
Entweder Du bietest nur harte Algorithmen an, oder akzeptierst auch die
weichen Algorithmen. Einen weichen Algorithmus anzubieten, um ihn dann
anschliessend nicht zu akzeptieren, ist brocken by design or
configuration. Die 534 ist nur für denn Fall vorgesehen, das der Client,
ohne Rücksicht auf den SASL-String im EHLO, einen weichen Algorithmus
verwenden will, den Du nicht angeboten hast. Es ist in diesem Fall
sicherer nach der 534 die TCP-Verbindung zu beenden und nicht darauf zu
warten das der Client ein QUIT sendet. Er könnte damit die Verbindung
unnötig lange offenhalten und damit einen DoS gegen den Server fahren. Es
ist nicht damit zu rechnen, das ein Client, obwohl der Server einen harten
Algorithmus angeboten, nach dem Versuch sich ohne Rücksicht auf das EHLO
sich mit einem weichen Algorithmus einzuloggen, doch noch einen harten
Algorithmus verwendet. Im Gegenteil ein solches Verhalten würde einem
Sniffer dann eine Kown Plaintext Attacke ermöglichen. Aus diesen Grund
halte ich die 534 sowieso nicht für stubenrein.
Im übrigen muss Du berücksichtigen das auch SASL von den Clienten nur
optional unterstützt werden muss. Es ist auch wie in älteren OE,NC und
Mozilla-Versionen zulässig, AUTH ohne SASL als private ESMTP Erweiterung
(AUTH=LOGIN) in Clienten zu implementieren. Ein guter Server sollte beides
anbieten. Ein guter Client sollte aber nur noch SASL verwenden, denn es
gibt praktisch keine Server die wenn sie AUTH unterstützen, SASL nicht
verstehen.
> Nun zu OE, da komme ich gar nicht weiter:
> WRITE:250-Shicks! 0.6 ready.
> 250-AUTH=LOGIN CRAM-MD5
> 250-AUTH LOGIN CRAM-MD5
> 250-SIZE
> 250-VRFY
> 250 HELP
> READ:AUTH LOGIN
> An dieser Stelle kann ich scheinbar Antworten was auch immer ich will,
> OE schickt als nächstes grundsätzlich IMMER
> READ:MAIL FROM: <gerson.kurz@localhost>
Wenn der Client beim AUTH LOGIN die Usernamen nicht mitliefert, musst Du
dem Clienten diesen aus der Nase ziehen. Das ist entsprechend SASL RFC
korrekt. Schaue dir dazu den SASL-RFC an und fragen den Clienten
entsprechend nach dem Username, wenn die AUTH LOGIN Antwort keinen
Parameter enthält.
> Spitze! Gibt es SMTP AUTH bei OE überhaupt?
Ja. Deine SASL Implementation ist unvollständig.
> Und kann bitte jemand den RFC neu schreiben, so
> dass er eindeutiger wird?...
Nö, du musst die RFC's verstehen lernen. Hint: der SASL Mechanismus LOGIN
ist nicht explizit sondern indirekt definiert. Damit er mit allen Clienten
funktioniert muss Du beide SASL-Variationen (Nicht Methoden)
implementieren.
Du benötigst also je nach unterstützten SASL-Mechanismus folgende Module:
MD5
SHA1
HMAC (für MD5 und SHA1)
Zufallszahlengeneratorn (für CRAM)
Zeitstempelgenerator (für CRAM)
CRAM (für MD5 und SHA1)
DIGEST (für DIGEST-MD5 und DIGEST-SHA1)
SASL (immer erforderlich)
SSL (für PLAIN und EXTERNAL)
und die Einzel-Module für die zu unterstützenden SASL Mechanismen.
Tip: Wenn Du mit Delphi klar kommst, schaue Dir den Source-Code des
Hamster an. Zumindest zum ausprobieren Deine Implementation kannst Du ihn
in der binär-Version benutzen. Dort ist sowohl die Client- als auch die
Server-Seite mit AUTH implementiert, und zwar für POP3 und SMTP.
Unterstützt werden PLAIN, LOGIN, CRAM-MD5, CRAM-SHA1 und EXTERNAL(SSL) mit
den Protokollen SMTP AUTH, POP AUTH. APOP wird ebenfalls unterstützt.
Für DIGEST-XXX, ISO, KERBEROS und SECURE-ID und das andere (MS) Geraffel
habe ich leider keinen passende Testserver bzw. die Hardware nicht
gefunden.
Hier noch ein Auszug aus den Vorrecherchen zur Hamster-Implementation:
Am Anfang standen die RFC 1320 und 1321. Sie definierten ein MD4 und MD5
welche als Ausgabe-Ergebnis ein MD4 bzw. MD5 Digest liefern. MD4 besitzt
inzwischen nur noch historischen Wert. Im letzten Monat wurde nun auch
SHA1 endlich in RFC 3174 standardisiert. SHA1 liefert ebenfalls einen
Digest. Der SHA1 Digest ist theoretisch sicherer als MD5 und kommt im
Gegensatz zu MD5 mit wesentlich weniger Konstanten aus. Gegen SHA1 ist, im
Gegensatz zu MD5, kein theoretischer Angriff bekannt. SHA1 liefert einen
160 Bit Digest (20 Byte), MD5 hingegen ein 128 Byte Digest (16 Byte). Der
Angriff gegen MD5 ist ausschliesslich theoretischer Natur das es nicht
ausreichend Recherzeitkapazität gibt ihn zu brechen. Setzt man die
Lebensdauer von MD5 in ein Verhältnis zu Lebensdauer von Passwörter ist
MD5 auch in den nächsten Jahrzehnten sicher. Bei SHA1 muss man bezüglich
der Sicherheit ebenfalls bedenken, das er in allen Aspekten noch nicht so
gut untersucht ist wie MD5. Meine Einschätzung ist das der Unterschied
zwischen MD5 und SHA1 bezüglich Sicherheit eher paranoid und eine
Glaubensfrage ist.
Um das Login sicherer zu gestalten wurden im laufe der Zeit
unterschiedliche Methoden für die einzelnen Protokolle entwickelt:
IMAP-Auth RFC 1731
POP-Auth RFC 1734
APOP RFC 1939
HTTP-Auth RFC 2069
Diese Protokolle nutzen unterschiedliche Haendling-Methoden für das
sichere Login benutzten aber teilweise die selben Hash-Funktionen und
Key-Verwaltungsverfahren. Z.B. verwendet APOP ein MD5-Digest (nicht
verwechseln mit SASL MD5-DIGEST) Zum einen sind das unverschlüsselte
"LOGIN" Verfahren und mehr oder minder sichere Handling Verfahren wie
KERBEROS,S/KEY und GSSAPI. Für POP und IMAP wurde dann erstmalig das für
beide Protokolle gemeinsame HMAC basierte CRAM-Verfahren mit RFC2095/2195
eingeführt. CRAM definiert selber nur CRAM-MD5 da zu diesem Zeitpunkt SHA1
noch nicht als RFC standardisiert war. Für HTTP wurde parallel ein
weiterentwickeltes Verfahren namens MD5-SESS mit RFC 2617 eingeführt, was
ebenfalls für andere Hash-Funktionen wie SHA1 vorbereitet war, ohne sie
selbst zu definieren. Um den Wildwuchs der einzelnen Handlingverfahren und
Hash-Methoden einen vernünftigen Rahmen zu geben und das vom jeweiligen
Server angebotene Verfahren automatisch auswählen zu können wurde dann mit
RFC 2222 SASL als Auswahlverfahren eingeführt. Dieser RFC definierte
sofort die SASL-Mechanismen für S/Key, Kerberos und GSSAPI und übernahm
LOGIN und CRAM-MD5 von IMAP/POP. In SMTP wurde SASL mit RFC 2554
übernommen. In RFC 2449 wurde SASL endgültig für POP3 definiert und in den
CAPA-Befehl verlagert. Bis zu diesem Zeitpunkt wurde SASL bei POP3, wie
bei IMAP im AUTH Befehl plaziert. Es wird heute noch von vielen POP3
Server SASL im AUTH Befehl angeboten, obwohl das nie so standardisiert
sondern nur von IMAP übernommen wurde. Inzwischen wurden weitere
SASL-Mechanismen Standardisiert die für alle Protokolle gültig sind. Das
sind:
PLAIN und RFC 2595 TLS/SSL unverschlüsselt da SSL an sich
EXTERNAL schon sicher ist
SECURID RFC 2808 für RSA-Chipkarten-Anwendungen SECURID
ermöglicht auch andere HASH-Funktionen als MD5
z.B. SHA1
ISO/IEC 9798-3 RFC 3163 für die Benutzung von Zertifikaten als
Ausweis fürs Login. Basiert auf der PKI-Infrastruktur
DIGEST-MD5 und RFC 2831 übernimmt die Digest-Methoden von HTTP und
MD5-SESS macht HTTP zu SASL konform. DIGEST ermöglicht auch
andere HASH-Funktionen als MD5 z.B. SHA1
OTP-MD5 RFC 2444 für One Time Passwords OTP ermöglicht auch
andere HASH-Funktionen als MD5 z.B. SHA1
ANONYMOUS RFC 2245 für anonymes Login
Dazu kommen dann die bekannten Mechanismen
KERBEROS Für homogene Umgebungen basierend auf Ticketserver
S/Key Für auf einanderfolgend abhängige Keys. Das
Verfahren ist nur schwer händelbar bei öffentlichen
Servern und eher gut für Intranetze
LOGIN Klartext-LOGIN
GSS-API Für Anwender-Applikationen in Verbindung mit Kerberos
Folgende Protokolle unterstützen inzwischen SASL:
LDAP,FTP,HTTP,POP3,ACAP,IMAP,SMTP
Für NNTP gibt es mit NNTP-Auth ebenfalls Ansätze dafür.
Gruss Joern Weber
--
em...@joernweber.de
Joern Weber
"Jakob Hirsch" <forg...@plonk.de> schrieb/wrote:
>> Also. Ich gebe bei EHLO als Server Extension AUTH mit. Im RFC wird als
>> Beispiel
>>
>> 250 AUTH CRAM-MD5 DIGEST-MD5
>
> Ich wüßte keinen Client, der DIGEST-MD5 benutzt.
Ich kenne leider auch keinen öffentlichen Server der das unterstützt.
Sonst gäbe es einen Clienten mehr der DIGEST-XXX unterstützt. Der Vorteil
von DIGEST-XXX gegenüber CRAM-XXX ist, das DIGEST denn Clienten vor
gefakte Server schützt.
>> 250 AUTH=LOGIN
>
> Ja, AFAIK ältere (<5) Versionen von OE.
Ja, diese Variante stammt aus der zeit vor SASL.
>> smtplib und ein paar Unix-Reader. Es gibt im Netz hinweise, das die
>> genannten beiden Clients SMTP AUTH nicht unterstützen, aber die
>> Hinweise beziehen sich auf jeweils alte Versionen der Clients (NS4.7,
>> OE4.x) - scheinbar gilt das auch noch für die aktuellen Clients ?
>
> Netscape unterstützt definitiv SMTP AUTH, ich weiß aber nicht, seit
> welcher Version. Die 4.7 aber auf jeden Fall.
Ja, leider aber auch nur in der älteren Variante mit vorgegebenen
250 AUTH=LOGIN
>> Genau so hätte ich das eigentlich erwartet. Jetzt das ganze über
>> Mozilla (0.9.9):
>>
>> READ:ZGVwcA==
>
> Nana. :)
<g>
>> 534 Authentication mechanism is too weak
>>
>> reagiert Mozilla scheinbar überhaupt nicht, und wenn ich nur
>
> Wie reagiert er denn und wie sollte er deiner Meinung nach reagieren?
534 ist IMHO obsolente.
>> "CRAM-MD5" angebe, macht Mozilla gar kein AUTH. Soviel zu
>> Standardtreue von Mozilla :(
>
> Wird CRAM-MD5 vom RFC zwingend verlangt? Ich glaube nicht.
Ack. Jedes AUTH-Verfahren ist optional.
Frank-Christian Kruegel
Kurz) wrote:
>Es geht um meinen eigenen selbstgeschriebenen Server (da gibt es also
>auch keine RPMs für ;), ich habe also die Frage: Wie schaut so eine
>SMTP-AUTH Kommunikation mit OE korrekt aus. Ohne "Server erfordert
>Authentifizierung", macht OE ja gar kein "AUTH LOGIN"; meine Frage ist
>also, wie "AUTH LOGIN" reagieren soll.
>
>Mir wäre sehr geholfen, wenn hier jemand ein SMTP-Protokoll einer
>erfolgreichen SMTP-AUTH Sitzung posten/schicken könnte. CRAM-MD5 kann
>OE nicht, oder?
Nimm Dir doch einfach mal eine funktionierende Implementierung,
vorzugsweise sendmail und sasl (siehe
http://www.sendmail.org/~ca/email/auth.html) und installier das. Wenn
das läuft, weißt Du wie es geht und kannst Deine eigene
Implementierung entsprechend anpassen.
Mit freundlichen Grüßen
Dipl.-Ing. Frank-Christian Krügel
IstDa Kommunikationssysteme