Hamster und gmx - demnächst nur noch per SSL möglich?
Wolfgang Jäth
Vor ein paar Tagen erhielt ich eine Nachricht von gmx, daß die anscheinend
alles auf SSL umstellen wollen. Um ehrlich zu sein, habe ich mich bisher aus
Faulheit um die Installation von SSL gedrückt. Inzwischen gips die in der
Hilfe angegebenen Links zum Bezug der SSL-Dateien
(http://sites.inka.de/ximera/hamster.html) leider anscheinend gar nicht
mehr. Im Skriptarchiv hab ich auch nix passendes gefunden. Kann mir jemand
sagen, wo man die sonst noch herbekommen kann?
Wolfgang
--
Wolfgang Bauer
> Hi,
Sind es die beiden Dateien OpenSSL-DLLs libeay32.dll und libssl32.dll
die Du brauchst? Ich habe sie hier noch in einem alten Hamsterverzeichnis.
Freundliche Grüße
Wolfgang
--
http://www.wolfgang-bauer.at
40tude-Dialog DER Newsreader unter Windows http://dialog.datalist.org/
Newsgruppe news:de.comm.software.40tude-dialog
40tude-Dialog Scriptwerkstatt http://4ds.siteboard.eu/
Willi Bornemann
"Alles auf SSL umstellen" habe ich aus
<cit>
Nach der Umstellung am 10.3.2009 kann Ihr Mailprogramm Sie nicht mehr an
unseren Mailservern anmelden, wenn die Optionen "APOP" oder "CRAM-MD5"
aktiviert sind. Bitte entfernen Sie ggf. die Einstellungen für diese
Optionen und wählen Sie stattdessen "SSL" oder "TLS" als sichere
Verbindung!
</cit>
nicht herausgelesen. Ich habe es so verstanden, daß jene user,
die SSL bereits verwenden die Einstellungen ändern müssen.
Hier habe ich aber eine Bitte an die Spezialisten: ich verwende SSL zum
Senden über Port 465 und habe CRAM-MD5 eingestellt. Welche, vom Hamster
angebotene Methode sollte ich denn zweckmäßigerweise verwenden? Und
sind sonst noch Änderungen erforderlich oder genügt das dann?
Gruß Willi
Alfred Peters
> Inzwischen gips die in
> der Hilfe angegebenen Links zum Bezug der SSL-Dateien
> (http://sites.inka.de/ximera/hamster.html) leider anscheinend gar nicht
> mehr.
<fah10v$7n1$2...@sapa.inka.de>
| Meine Hamster-SSL-Seiten sind ziehen um, und zwar nach
| http://www.ximera.de/hamster.html
|
| Die Seiten bei INKA werden im September entfernt.
[Anm: September := September *2007*]
> Im Skriptarchiv hab ich auch nix passendes gefunden.
Links:
| Hamster und SSL (http://www.ximera.de/)
| Hamster und SSL/TLS einstellen.
HTH
Alfred
--
09181.9
Stefan Reuther
Ich bin über mehrere FAQ-/Link-Seiten (keine Ahnung welche) bei
<http://www.ximera.de/hamster.html> gelandet. Beim Versuch, das zu
Installieren habe ich dann allerdings festgestellt, dass ich die
SSL-DLLs doch schon installiert hatte :-), kann also nicht sagen, ob die
Libs von dieser Seite funktionieren.
Stefan
Heiko Studt
> <cit>
> Nach der Umstellung am 10.3.2009 kann Ihr Mailprogramm Sie nicht mehr an
> unseren Mailservern anmelden, wenn die Optionen "APOP" oder "CRAM-MD5"
> aktiviert sind. Bitte entfernen Sie ggf. die Einstellungen für diese
> Optionen und wählen Sie stattdessen "SSL" oder "TLS" als sichere
> Verbindung!
> </cit>
Also bislang geht "CRAM-MD5 over TSL" (mit Becky).
Ich würde CRAM-MD5 solange aktiviert lassen, bis es nicht mehr geht...
und dazu hinzu SSL nehmen.
MFG
Heiko Studt
--
www.bash.org #205970
does anyone here have a computer?
Willi Bornemann
> Am 08.03.2009 schrieb Willi Bornemann:
>
>> <cit>
>> Nach der Umstellung am 10.3.2009 kann Ihr Mailprogramm Sie nicht
>> mehr an unseren Mailservern anmelden, wenn die Optionen "APOP" oder
>> "CRAM-MD5" aktiviert sind. Bitte entfernen Sie ggf. die
>> Einstellungen für diese Optionen und wählen Sie stattdessen "SSL"
>> oder "TLS" als sichere Verbindung!
>> </cit>
>
> Also bislang geht "CRAM-MD5 over TSL" (mit Becky).
Muß es ja auch! Umstellung ist erst am 10. (s.o.-da stehts)
> Ich würde CRAM-MD5 solange aktiviert lassen, bis es nicht mehr geht...
> und dazu hinzu SSL nehmen.
Bei den SSL Anmeldeverfahren die Hamster anbietet (unter
Mailserver-Einstellungen)
gibt es zur Auswahl:
DIGEST-MD5
CRAM-SHA1
CRAM-MD5
LOGIN
PLAIN
Davon fällt MD5 ja nun weg- meine Frage war, welches der verbleibenden
Verfahren das beste ist. Irgendwelche Unterschiede (deren Vor-und
Nachteile ich mangels Kenntnis der Materie nicht kenne) wird es ja
anzunehmenderweise geben.
Gruß Willi
Wilfried Kramer
> Wolfgang Jäth schrieb:
>> Vor ein paar Tagen erhielt ich eine Nachricht von gmx, daß die
>> anscheinend alles auf SSL umstellen wollen. Um ehrlich zu sein, habe
>> ich mich bisher aus Faulheit um die Installation von SSL gedrückt.
> "Alles auf SSL umstellen" habe ich aus
>
> <cit>
> Nach der Umstellung am 10.3.2009 kann Ihr Mailprogramm Sie nicht mehr an
> unseren Mailservern anmelden, wenn die Optionen "APOP" oder "CRAM-MD5"
> aktiviert sind.
Witzigerweise ist diese Umstellung bei meinem Account bereits jetzt
schon passiert. Jedenfalls hatte sich der Hamster tagelang über
fehlendes SASL beschwert.
> Bitte entfernen Sie ggf. die Einstellungen für diese
> Optionen und wählen Sie stattdessen "SSL" oder "TLS" als sichere
> Verbindung!
> </cit>
>
> nicht herausgelesen. Ich habe es so verstanden, daß jene user,
> die SSL bereits verwenden die Einstellungen ändern müssen.
Das Problem ist, daß nach meinem Wissen bisher SSL nur dann
funktionierte, wenn Du einen Premium Account hattest. Mit dem
klassischen Free Account konntest Du bis jetzt mit den diversen
Verfahren wenigstens die Übertragung des Passworts sichern.
Die Änderung bei GMX ist also, daß diese verschiedenen Verfahren nicht
mehr funktionieren werden. Was im Prinzip auch überflüssig ist, wenn die
gesamte Session verschlüsselt ist.
Ohne SSL ist es jetzt allerdings wieder wie vor 10 Jahren.
> Hier habe ich aber eine Bitte an die Spezialisten: ich verwende SSL zum
> Senden über Port 465 und habe CRAM-MD5 eingestellt. Welche, vom Hamster
> angebotene Methode sollte ich denn zweckmäßigerweise verwenden?
User/Pass bei POP3S, das habe ich so in Betrieb.
Und LOGIN oder PLAIN bei SMTPS würde ich versuchen, habe ich aber nicht
probiert.
> Und sind sonst noch Änderungen erforderlich oder genügt das dann?
Jedenfalls der Abruf gelingt so schon.
Wilfried
--
Na ja, mit Windows kann man es ja machen ;-), das verzeiht so manchen
Fehler, selbst hat es ja auch ein paar. [Sabine Schulz in hadeta~]
Wolfgang Jäth
>
>> Vor ein paar Tagen erhielt ich eine Nachricht von gmx, daß die
>> anscheinend
>> alles auf SSL umstellen wollen. Um ehrlich zu sein, habe ich mich bisher
>> aus
>> Faulheit um die Installation von SSL gedrückt. Inzwischen gips die in der
>> Hilfe angegebenen Links zum Bezug der SSL-Dateien
>> (http://sites.inka.de/ximera/hamster.html) leider anscheinend gar nicht
>> mehr. Im Skriptarchiv hab ich auch nix passendes gefunden. Kann mir
>> jemand
>> sagen, wo man die sonst noch herbekommen kann?
>
> Sind es die beiden Dateien OpenSSL-DLLs libeay32.dll und libssl32.dll
> die Du brauchst? Ich habe sie hier noch in einem alten Hamsterverzeichnis.
Ja; aber dank Stefans Link hab ich sie schon.
Wolfgang
--
Wolfgang Jäth
Doch, tun sie anscheinend (gerade ausprobiert). Danke.
Dafür stellt sich schon gleich die nächste Frage: Kann es sein, daß
HamFetchMail für die SSL-Einstellungen nicht die Defaulteinstellungen aus
der Mailserverkonfiguration übernehmen kann?
Wolfgang, sich fragend, warum er eigentlich die Frage nicht nach hdm
gepostet hat, wie er es vor hatte :-)
--
Wolfgang Jäth
"Willi Bornemann" <ohnedas...@a1.net> schrieb im Newsbeitrag ...
>
>> Vor ein paar Tagen erhielt ich eine Nachricht von gmx, daß die
>> anscheinend alles auf SSL umstellen wollen. Um ehrlich zu sein, habe
>> ich mich bisher aus Faulheit um die Installation von SSL gedrückt.
>> Inzwischen gips die in der Hilfe angegebenen Links zum Bezug der
>> SSL-Dateien (http://sites.inka.de/ximera/hamster.html) leider
>> anscheinend gar nicht mehr. Im Skriptarchiv hab ich auch nix
>> passendes gefunden. Kann mir jemand sagen, wo man die sonst noch
>> herbekommen kann?
>
> "Alles auf SSL umstellen" habe ich aus
>
> <cit>
> Nach der Umstellung am 10.3.2009 kann Ihr Mailprogramm Sie nicht mehr an
> unseren Mailservern anmelden, wenn die Optionen "APOP" oder "CRAM-MD5"
> aktiviert sind. Bitte entfernen Sie ggf. die Einstellungen für diese
> Optionen und wählen Sie stattdessen "SSL" oder "TLS" als sichere
> Verbindung!
> </cit>
>
> nicht herausgelesen. Ich habe es so verstanden, daß jene user,
> die SSL bereits verwenden die Einstellungen ändern müssen.
Aus '[...] wählen Sie *stattdessen* "SSL" oder "TLS" [...]' (Hervorhebung
von mir)? :-)
Wolfgang
--
Wolfgang Jäth
>
> Das Problem ist, daß nach meinem Wissen bisher SSL nur dann
> funktionierte, wenn Du einen Premium Account hattest.
<ironisch> Die Email ging ja auch an "GMX Premium-Kunden <mem...@gmx.net>"
</ironisch>
(was ich aber eigentlich gar nicht bin)
Wolfgang
--
Heiko Studt
> Witzigerweise ist diese Umstellung bei meinem Account bereits jetzt
> schon passiert. Jedenfalls hatte sich der Hamster tagelang über
> fehlendes SASL beschwert.
Vermutlich bieten sie einfach CRAM-MD5 nicht mehr in der CAPA an.
> Das Problem ist, daß nach meinem Wissen bisher SSL nur dann
> funktionierte, wenn Du einen Premium Account hattest. Mit dem
> klassischen Free Account konntest Du bis jetzt mit den diversen
> Verfahren wenigstens die Übertragung des Passworts sichern.
Also ich habe definitiv keinen Premium-Account, bin aber schon seit
98 oder 99 dabei. Bei mir funktioniert SSL (genauer: TLS).
> Die Änderung bei GMX ist also, daß diese verschiedenen Verfahren nicht
> mehr funktionieren werden. Was im Prinzip auch überflüssig ist, wenn die
> gesamte Session verschlüsselt ist.
Nein, siehe anderen Post.
Du verschlüsselst nur Punkt-zu-Punkt. Ob einer der Punkte davon unsicher
ist, weisst Du per se nicht. Wenn Du keine Zertifikatsprüfung machst,
kann man leicht einen man-in-the-middle einführen.
> Ohne SSL ist es jetzt allerdings wieder wie vor 10 Jahren.
ACK.
Heiko Studt
> > Also bislang geht "CRAM-MD5 over TSL" (mit Becky).
> Muß es ja auch! Umstellung ist erst am 10. (s.o.-da stehts)
Deswegen "bislang". Und müssen muss es nicht. Bislang ging
auch einfaches CRAM-MD5.
> > Ich würde CRAM-MD5 solange aktiviert lassen, bis es nicht mehr geht...
> > und dazu hinzu SSL nehmen.
> Bei den SSL Anmeldeverfahren die Hamster anbietet (unter
Du verhexelst SSL und SASL. Das sind zwei grundsätzlich verschiedene
Dinge. SSL verschlüsselt die Verbindung, SASL ist ein Anmeldesystem-
Framework (für TCP-Netzwerkprotokolle).
> gibt es zur Auswahl:
Jain. Nimm einfach alles, dann wird das bestmögliche verwendet. Wenn GMX
meckern sollte, schalte CRAM-MD5 ab. Es ist nämlich keine Auswahl eines
Verfahrens (Groupbox), sondern die Auswahl derjenigen, die Hamster
probieren soll.
> DIGEST-MD5
> CRAM-SHA1
> CRAM-MD5
> LOGIN
> PLAIN
> Davon fällt MD5 ja nun weg- meine Frage war, welches der verbleibenden
> Verfahren das beste ist. Irgendwelche Unterschiede (deren Vor-und
> Nachteile ich mangels Kenntnis der Materie nicht kenne) wird es ja
> anzunehmenderweise geben.
LOGIN und PLAIN haben keinerlei Verschlüsselung des Passwortes und auch
keine Authentifizierung des Servers/Clients ausserhalb des Passwortes.
Man-In-The-Middle-Attacken sind so theoretisch möglich.
Praktisch läuft die Verbindung aber über SSL - und da man annimmt, dass
dies sicher ist, werden die Passwörter verschlüsselt übertragen - aber
die beiden Endpunkte der verschlüsselten Verbindung sind wiederum
'unsicher'.
Daher würde ich persönlich zum Doppel-gemoppelten SSL + CRAM-* greifen.
Soweit ich es in Erinnerung habe, ist MD5 'geknackt' worden, während
SHA1 noch immer nur theoretische (bzw nicht so gravierende) Probleme
hatte. Hier bedeutet 'geknackt' aber vorerst noch "für Normalsterbliche
dennoch brauchbar".
Das derzeit im Hamster sicherste Verfahren dürfte CRAM-SHA1 sein.
Wolfgang Bauer
Ich /bin/ Premium Kunde habe aber solch eine Mail /nicht/ bekommen.
Weil ich mich schon immer per pop.gmx.net - TLS - Port 995 und
mail.gmx.net - TLS - Port 465 einlogge? (übrigens nicht mit dem Hamster
sondern The Bat!
Freundliche Grüße
Wolfgang
X'Post: hamster.de.newuser,hamster.de.misc
F'Up2 : hamster.de.misc
Willi Bornemann
> Am 08.03.2009 schrieb Willi Bornemann:
>> Bei den SSL Anmeldeverfahren die Hamster anbietet (unter
>
> Du verhexelst SSL und SASL. Das sind zwei grundsätzlich verschiedene
> Dinge. SSL verschlüsselt die Verbindung, SASL ist ein Anmeldesystem-
> Framework (für TCP-Netzwerkprotokolle).
Ja, danke, nach längerem Schiefhalten des Kopfes habe ich das jetzt auch
verstanden. Ich hatte mich da ja komplett verrannt.
>> Davon fällt MD5 ja nun weg- meine Frage war, welches der
>> verbleibenden Verfahren das beste ist. Irgendwelche Unterschiede
>> (deren Vor-und Nachteile ich mangels Kenntnis der Materie nicht
>> kenne) wird es ja anzunehmenderweise geben.
>
> LOGIN und PLAIN haben keinerlei Verschlüsselung des Passwortes und
> auch keine Authentifizierung des Servers/Clients ausserhalb des
> Passwortes. Man-In-The-Middle-Attacken sind so theoretisch möglich.
>
> Praktisch läuft die Verbindung aber über SSL - und da man annimmt,
> dass dies sicher ist, werden die Passwörter verschlüsselt übertragen
> - aber die beiden Endpunkte der verschlüsselten Verbindung sind
> wiederum 'unsicher'.
>
> Daher würde ich persönlich zum Doppel-gemoppelten SSL + CRAM-*
> greifen.
>
> Soweit ich es in Erinnerung habe, ist MD5 'geknackt' worden, während
> SHA1 noch immer nur theoretische (bzw nicht so gravierende) Probleme
> hatte. Hier bedeutet 'geknackt' aber vorerst noch "für
> Normalsterbliche dennoch brauchbar".
>
> Das derzeit im Hamster sicherste Verfahren dürfte CRAM-SHA1 sein.
Danke, für die ausführliche Erläuterung, jetzt habe ich so halbwegs
verstanden (hoffe ich), worums geht.
Gruß Willi
Willi Bornemann
> "Willi Bornemann" <ohnedas...@a1.net> wrote:
> Das Problem ist, daß nach meinem Wissen bisher SSL nur dann
> funktionierte, wenn Du einen Premium Account hattest. Mit dem
> klassischen Free Account konntest Du bis jetzt mit den diversen
> Verfahren wenigstens die Übertragung des Passworts sichern.
>
> Die Änderung bei GMX ist also, daß diese verschiedenen Verfahren nicht
> mehr funktionieren werden. Was im Prinzip auch überflüssig ist, wenn
> die gesamte Session verschlüsselt ist.
> Ohne SSL ist es jetzt allerdings wieder wie vor 10 Jahren.
Ich habe nur einen normalen free-account und da hat es (bisher
jedenfalls) trotzden funktioniert. Ich glaube, ich habe das irgendwann
vor langer Zeit als "Geheimtip" gelesen, daß das über Port 465 geht.
Bei mir gings gestern noch, ohne Problem.
----------
[...]
> {121c} TSSLConnection.Create
> {121c} TSSLContext.Destroy
> {121c} TSSLConnection.Connect
> {121c} Verify ok: depth=1 /C=ZA/ST=Western
> Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services
> Division/CN=Thawte Premium Server
> CA/emailAddress=premium...@thawte.com
> {121c} Verify ok: depth=0
> /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=mail.gmx.net
> {121c} TSSLConnection.Info
> {121c} Secure connection with SSLv3, cipher
> DHE-RSA-AES256-SHA, 256 secret bits (256 total)
> {121c} TClientSocketSMTP.Received:
> 220-mail.gmx.net GMX Mailservices ESMTP {mp055}
> {121c} TClientSocketSMTP.Login
> {121c} TClientSocketSMTP > EHLO OEM1
> {121c} TClientSocketSMTP.Received:
> 250-mail.gmx.net GMX Mailservices
> 250-8BITMIME
> 250-ENHANCEDSTATUSCODES
> 250-SIZE
> 250-AUTH=LOGIN CRAM-MD5 PLAIN
> [...]
> {121c} TClientSocketSMTP < 250 STARTTLS
> 250-AUTH CRAM-MD5 LOGIN PLAIN
> 250-AUTH=LOGIN CRAM-MD5 PLAIN
> 250-SIZE
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250-mail.gmx.net GMX Mailservices
----------
> Und LOGIN oder PLAIN bei SMTPS würde ich versuchen, habe ich aber
> nicht probiert.
>
>> Und sind sonst noch Änderungen erforderlich oder genügt das dann?
>
> Jedenfalls der Abruf gelingt so schon.
Ich werde wohl bis morgen warten und dann einfach mal drauflosprobieren.
(Versuch macht kluch - mit der Methode bin ich eigentlich bis jetzt ganz
gut gefahren, Zeit hab ich ja genug)
Gruß Willi
Willi Bornemann
> "Willi Bornemann" <ohnedas...@a1.net> schrieb im Newsbeitrag ...
>> nicht herausgelesen. Ich habe es so verstanden, daß jene user,
>> die SSL bereits verwenden die Einstellungen ändern müssen.
>
> Aus '[...] wählen Sie *stattdessen* "SSL" oder "TLS" [...]'
> (Hervorhebung von mir)? :-)
Ja, danke für den Denkanstoß. Ich hoffe, ich bin jetzt wieder raus aus
dem Wald, in dem ich stand.
Gruß Willi
Heiko Studt
> (Versuch macht kluch - mit der Methode bin ich eigentlich bis jetzt ganz
> gut gefahren,
Du solltest mal anfangen zu programmieren...
> Zeit hab ich ja genug)
...und Hamster 3.0 vorstellen!
PS: Hast Du es GUUUUUUUT! :-]
PPS: Ich weiss natürlich gar nicht, warum Du die Zeit hast...
MFG, f'up2
Heiko Studt
--
www.bash.org #204432
hmmm first thing to do when one gets home is .... check spam for emails
Wolfgang Jäth
>
>Jain. Nimm einfach alles, dann wird das bestmögliche verwendet. Wenn GMX
>meckern sollte, schalte CRAM-MD5 ab.
Wobei man IMHO CRAM-MD5 prophylaktisch auch einfach so abschalten kann;
erstens ist der Verschlüsselungsalgorithmus eh nicht mehr sicher (s. u.),
und zweitens gips immer wieder vereinzelt Fälle, in denen das Probleme
bereitet (ich denke da an diese ominöse Meldung 'server supported charset
utf8, but Hamster not').
>> Davon fällt MD5 ja nun weg- meine Frage war, welches der verbleibenden
>> Verfahren das beste ist. Irgendwelche Unterschiede (deren Vor-und
>> Nachteile ich mangels Kenntnis der Materie nicht kenne) wird es ja
>> anzunehmenderweise geben.
>
>LOGIN und PLAIN haben keinerlei Verschlüsselung des Passwortes und auch
>keine Authentifizierung des Servers/Clients ausserhalb des Passwortes.
>Man-In-The-Middle-Attacken sind so theoretisch möglich.
>
>Praktisch läuft die Verbindung aber über SSL - und da man annimmt, dass
>dies sicher ist, werden die Passwörter verschlüsselt übertragen - aber
>die beiden Endpunkte der verschlüsselten Verbindung sind wiederum
>'unsicher'.
>
>Daher würde ich persönlich zum Doppel-gemoppelten SSL + CRAM-* greifen.
>
>Soweit ich es in Erinnerung habe, ist MD5 'geknackt' worden, während
>SHA1 noch immer nur theoretische (bzw nicht so gravierende) Probleme
>hatte. Hier bedeutet 'geknackt' aber vorerst noch "für Normalsterbliche
>dennoch brauchbar".
Jein. /Wenn/ jemand tatsächlich einem ernsthaften Angriff ausgesetzt sein
sollte, dann ist MD5 für den Angreifer kein Hinderniss mehr. Er braucht nur
genug Daten aufzeichen (~5 Minuten), dann kann er den Schlüssel binnen
Sekunden ausrechnen. Die Frage ist allerdings, welchen Gewinn verspricht
sich ein Angreifer bei einer Privatperson? Andererseits, solange /kein/
Angriff stattfindet, ist /jegliches/ Verschlüsselungsverfahren genaugenommen
überflüssig.
>Das derzeit im Hamster sicherste Verfahren dürfte CRAM-SHA1 sein.
AOL.
Wolfgang
--
Thomas Weisbach
ich raff's nicht!
Könnte mir mal jemand eine Schritt für Schritt Anleitung geben, was ich
machen muss, damit mein Hamster Version 2.1 (Build 2.1.0.15) wie bisher
gewohnt meinen GMX-Account abruft?
Vielen Dank für die Mühe...
--
Mit freundlichen Grüßen!
Thomas Weisbach
Willi Bornemann
> Ähem, ich steh hier wie die Kuh vor'm neuen Tor... Tut mir leid, aber
> ich raff's nicht!
>
> Könnte mir mal jemand eine Schritt für Schritt Anleitung geben, was
> ich machen muss, damit mein Hamster Version 2.1 (Build 2.1.0.15) wie
> bisher gewohnt meinen GMX-Account abruft?
>
> Vielen Dank für die Mühe...
Also, wie ich es im Augenblick sehe, müssen wir gar nix ändern,
zumindest bei mir läuft alles wie gehabt. (Sturm im Wasserglas?)
Gruß Willi
Willi Bornemann
>> Das derzeit im Hamster sicherste Verfahren dürfte CRAM-SHA1 sein.
>
> AOL.
Tja, jetzt wirds erst richtig lustig!
Ich hatte erstmal gar nix verändert, um zu sehen, was passiert. Der
Abruf der pop3 Postfächer funktioniert wie gehabt. Da verwende ich aber
kein SSL und für die Anmeldung habe ich im Hamster alle Optionen
angehakt.
Aber dann kam die Überraschung. Nachdem ja laut GMX CRAM-MD5 nicht mehr
funktioniert habe ich im Hamster umgestellt auf CRAM-SHA1 und alle
anderen Optionen deaktiviert gelassen.(so hatte ich es auch bisher
eingestellt) Dann wollte ich probehalber ein mail versenden - was
passiert?:
----------------
ERR {b24} mail.gmx.at: No valid SASL mechanism for AUTH found!
ERR {b24} mail.gmx.at: "CRAM-MD5 LOGIN PLAIN" Hamster: "DIGEST-MD5
CRAM-SHA1 CRAM-MD5 LOGIN PLAIN" User: "CRAM-SHA1"
WAR {b24} Verbindung zu mail.gmx.at (Port 465) nicht möglich,
Fehlermeldung: " ("250 STARTTLS
250-AUTH CRAM-MD5 LOGIN PLAIN
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-SIZE
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-mail.gmx.net GMX Mailservices")"
2009.03.10 22:28:43 I {b24} {smtp to mail.gmx.at} Verbindung
abbauen...
2009.03.10 22:28:43 d {b24} TClientSocketSMTP.Disconnect
2009.03.10 22:28:43 d {b24} TSSLConnection.Shutdown
---------------
Überraschung! Ich also keck wieder zurückgestellt auf CRAM-MD5 und - man
glaubt es nicht- das mail wird ohne Meckern angenommen und
weiterbefördert.
---------------
{890} TClientSocketSMTP < 250 STARTTLS
250-AUTH CRAM-MD5 LOGIN PLAIN
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-SIZE
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-mail.gmx.net GMX Mailservices
{890} TClientSocketSMTP > AUTH CRAM-MD5
{890} TClientSocketSMTP.Received: 334 PDMyMjMuMTIzNjcyMDU5NkBtcDAxNT4=
{890} TClientSocketSMTP < 334 PDMyMjMuMTIzNjcyMDU5NkBtcDAxNT4=
{890} TClientSocketSMTP > [...authorization...]
{890} TClientSocketSMTP.Received: 235 2.7.0 Go ahead {mp015}
{890} TClientSocketSMTP < 235 2.7.0 Go ahead {mp015}
{890} {sendmail mail.gmx.at} Verschicke E-Mail "42425.msg"
---------------
Die spinnen, die Rö^^ GMXer!
Gruß Willi (der jetzt erstmal alles lässt, wie es "immer schon" war)
Heiko Studt
> und zweitens gips immer wieder vereinzelt Fälle, in denen das Probleme
> bereitet (ich denke da an diese ominöse Meldung 'server supported charset
> utf8, but Hamster not').
Das ist DIGEST-*
> >Soweit ich es in Erinnerung habe, ist MD5 'geknackt' worden, während
> >SHA1 noch immer nur theoretische (bzw nicht so gravierende) Probleme
> >hatte. Hier bedeutet 'geknackt' aber vorerst noch "für Normalsterbliche
> >dennoch brauchbar".
> Jein. /Wenn/ jemand tatsächlich einem ernsthaften Angriff ausgesetzt sein
> sollte, dann ist MD5 für den Angreifer kein Hinderniss mehr. Er braucht nur
> genug Daten aufzeichen (~5 Minuten), dann kann er den Schlüssel binnen
> Sekunden ausrechnen.
'genügend Daten' dürfte falsch sein.
'genügend verschlüsselte Daten' ist sicher richtiger.
5 Minuten einer Anmeldeprozedur ist halt kein Problem, da dort auch
nicht mehr Daten übertragen/entschlüsselt werden wie bei 10 Sekunden...
> Die Frage ist allerdings, welchen Gewinn verspricht
> sich ein Angreifer bei einer Privatperson? Andererseits, solange /kein/
> Angriff stattfindet, ist /jegliches/ Verschlüsselungsverfahren genaugenommen
> überflüssig.
Nein, Aufwand/Nutzen.
Wenn es keinen Aufwand macht (und 5 Minuten *sind* Aufwand), nutzt jeder
noch so kleine Datensatz. Wenn aber jeder davon Aufwand bedeutet, wird
man nur bei gezielten oder großen Attacken (auf GMX z.B.) das machen.
Gegen gezielte Attacken ist man als Privatperson ohnehin machtlos,
alleine social engeneering ist schön gefährlich... und dass man bei
fast jedem PC von CD booten kann ist eine gezielte, lokale Attacke
praktisch ohne Gegenwehr... *bg*
Wolfgang Jäth
>> >SHA1 noch immer nur theoretische (bzw nicht so gravierende) Probleme
>> >hatte. Hier bedeutet 'geknackt' aber vorerst noch "für Normalsterbliche
>> >dennoch brauchbar".
>
>> Jein. /Wenn/ jemand tatsächlich einem ernsthaften Angriff ausgesetzt sein
>> sollte, dann ist MD5 für den Angreifer kein Hinderniss mehr. Er braucht
>> nur
>> genug Daten aufzeichen (~5 Minuten), dann kann er den Schlüssel binnen
>> Sekunden ausrechnen.
>
>'genügend Daten' dürfte falsch sein.
>'genügend verschlüsselte Daten' ist sicher richtiger.
Das ist in dem Fall kein Unterschied.
>5 Minuten einer Anmeldeprozedur ist halt kein Problem, da dort auch
>nicht mehr Daten übertragen/entschlüsselt werden wie bei 10 Sekunden...
5 Minuten /Pause/ würde ich jetzt nicht unbedingt als 'Daten' bezeichnen.
>> Die Frage ist allerdings, welchen Gewinn verspricht
>> sich ein Angreifer bei einer Privatperson? Andererseits, solange /kein/
>> Angriff stattfindet, ist /jegliches/ Verschlüsselungsverfahren
>> genaugenommen
>> überflüssig.
>
>Nein, Aufwand/Nutzen.
>Wenn es keinen Aufwand macht (und 5 Minuten *sind* Aufwand), nutzt jeder
>noch so kleine Datensatz. Wenn aber jeder davon Aufwand bedeutet, wird
>man nur bei gezielten oder großen Attacken (auf GMX z.B.) das machen.
Bei welchem Nutzen?
>Gegen gezielte Attacken ist man als Privatperson ohnehin machtlos,
>alleine social engeneering ist schön gefährlich...
Jein. Viele Leute sind im Internet viel zu vertrauensselig. Inzwischen
bekommt man mit googeln schon fast mehr (und vor allem sehr viel leichter)
Informationen über jemanden Bestimmten, als auf viele andere Weisen.
>und dass man bei
>fast jedem PC von CD booten kann ist eine gezielte, lokale Attacke
>praktisch ohne Gegenwehr... *bg*
Naja, wenn jemand physikalischen Zugriff auf die Hardware hat (und irgendwie
muss man ja die CD ins Laufwerk bekommen), dann ist sowieso jede
Abwehrbemühung zu spät.
Wolfgang
--
Jens Weissenburger
mit einer Art Zusammenfassung gefunden. Ich habe vom GMX noch keine
Nachricht, würde aber gern vorbereitet sein ;)
Im Script frage ich derzeit so ab:
$Hamster->ControlRunFetchMail("pop.gmx.de", "pop3", "\$2", "", "GMX");
Was muss ich daran ändern und was im Hamster?
Danke und viele Grüße,
Jens
Wolfgang Bauer
> Ui, irgendwie habe ich jetzt den Anschluss verloren und keinen Beitrag
> mit einer Art Zusammenfassung gefunden. Ich habe vom GMX noch keine
> Nachricht, würde aber gern vorbereitet sein ;)
http://www.wolfgang-bauer.at/gmx/gmx-einstellungen.html
> Im Script frage ich derzeit so ab:
> $Hamster->ControlRunFetchMail("pop.gmx.de", "pop3", "\$2", "", "GMX");
> Was muss ich daran ändern und was im Hamster?
Was bedeutet denn der Backslash bei "\$2"? Bei mir steht im Script -
HamFetchMail ("pop.gmx.net", "995", "$1","", "Wolfgang" , "",1,1,0)
LeaveOnServer ^
SSLMode ^
,--[ Alfred Peters ]
¦ # HamFetchMail ( "<server>", "port(KontoTyp)", "<user>","<pass>",
¦ # "<destuser>", "<filterSektion>", <LeaveOnServer>,
¦ # <SSLMode>, <SSLVerify>, <SSLCaFile> )
¦ #
¦ # Der Parameter <SSLMode> ist ein Integer und gibt an, ob und wie
¦ SSL/TLS
¦ # verwendet wird:
¦ # 0 - SSL/TLS abgeschaltet
¦ # 1 - SSL auf separatem Port (sPOP3 bzw, sSMTP)
¦ # 2 - TLS, wenn möglich
¦ # 3 - TLS wird erzwungen
¦ #
¦ # Der Parameter <SSLVerify> ist ebenfalls Integer und regelt die
¦ # Überprüfung der fremden Server-Zertifikate:
¦ # 0 - Zertifikatsüberprüfung abgeschaltet
¦ # 1 - Zertifikatsüberprüfung, falls Zertifikat vorgelegt
¦ # 2 - Zertifikatsüberprüfung immer
¦ # 3 - Zertifikatsüberprüfung immer und Vergleich des Serverzertifikats
¦ # mit lokaler Kopie
`----
Freundliche Grüße
Wolfgang
Heiko Studt
> Im Script frage ich derzeit so ab:
> $Hamster->ControlRunFetchMail("pop.gmx.de", "pop3", "\$2", "", "GMX");
> Was muss ich daran ändern und was im Hamster?
Du nutzt OLE, oder? Was ist das denn für eine Scriptsprachen, dass Du
Dollarzeichen maskieren musst? PHP? Kennst Du "'"? ;-)
Du willst folgendes nutzten (siehe in der Hamster_de.hlp fuer Details):
| ControlRunFetchMailTLS( <server>, <port>, <user>, <pass>, <filter>, <SSLMode>, <SSLVerify>, <SSLCaFile> )
| ControlRunSendMailTLS(<server>, <port>, <from-select> <SSLMode>, <SSLVerify>, <SSLCaFile>)
| ControlRunSendMailAuthTLS( <server>, <port>, <user>, <pass>, <from-select> <SSLMode>, <SSLVerify>, <SSLCaFile> )
BTW: Bei einer schnellen Suche nach der Hilfe habe ich http://home.wtal.de/fritzwww/hamster/
gefunden... meine Guete, ist das lang her. :=)
Jens Weissenburger
> Was ist das denn für eine Scriptsprachen
Den ganzen Mail- und Newskram behandel ich via Perl und ' kenne ich ;-)
Danke!
Gruß, Jens
Jens Weissenburger
news:140309.0850...@home.wolfgang-bauer.at:
> http://www.wolfgang-bauer.at/gmx/gmx-einstellungen.html
Und wie bekomme ich die Port-Auswahl 995 hin? Bei mir steht da nur pop
zur Auswahl.
> Was bedeutet denn der Backslash bei "\$2"?
Das ist nur zum "Escapen", da das aus einem Perl-Script abläuft.
> Bei mir steht im Script
Danke, werde ich mal so testen, wenn ich eine Idee bekomme, wie Port
995 zur Auswahl steht ;)
Gruß, Jens
Wolfgang Bauer
>> http://www.wolfgang-bauer.at/gmx/gmx-einstellungen.html
> Und wie bekomme ich die Port-Auswahl 995 hin? Bei mir steht da nur pop
> zur Auswahl.
pop löschen und 995 eintragen.
Jens Weissenburger
Also das Abholen funktioniert. Beim Senden bekomme ich die Meldung
ERR {1c14} OpenSSL error: SSL_connect: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number
WAR {1c14} SSL connection failed
ERR {1c14} Fehler beim Verbinden mit mail.gmx.de:
ERR {1c14} Exception[Exception] Error starting SSL
WAR {1c14} Verbindungsversuch mit mail.gmx.de gescheitert!
Das ist die Zeile im Perl-Script:
$Hamster->ControlRunSendMailAuthTLS( "mail.gmx.de", "587", "\$2", "",
"foo\@gmx\.net", 1, 0, 0);
Gruß, Jens
P.S.: ja, ' kenne ich ;-)
Jens Weissenburger
> Und wie bekomme ich die Port-Auswahl 995 hin? Bei mir steht da nur
> pop zur Auswahl.
OK, einfach in das Feld eintrage, war die Lösung ;)
Gruß, Jens
Wolfgang Bauer
> Das ist die Zeile im Perl-Script:
> $Hamster->ControlRunSendMailAuthTLS( "mail.gmx.de", "587", "\$2", "", "foo\@gmx\.net", 1, 0, 0);
Da kann ich Dir nicht mehr folgen. Wie das in einem Perlscript sein muß,
keine Ahnung. Ohne Perl sieht die Zeile bei mir so aus.
HamSendMailAuth( "mail.gmx.net","587","$1" )
Jens Weissenburger
news:140309.1521...@home.wolfgang-bauer.at:
> sein muß, keine Ahnung. Ohne Perl sieht die Zeile bei mir so aus.
> HamSendMailAuth( "mail.gmx.net","587","$1" )
Ah, OK ... ohne TLS ... einfach nur den Port ändern, gegenüber der
bisherigen Methode.
Damit geht's jetzt zumindest.
Gruß, Jens
Alfred Peters
Klar. Dann geht das Passwort aber unverschlüsselt über die Leitung.
# $Hamster->ControlRunSendMailAuthTLS( "mail.gmx.de", "587", "\$2", "", "foo\@gmx\.net", 1, 0, 0);
Wolfgang benutzt "mail.gmx.net" und nicht "mail.gmx.de".
Für SSL müsste es wohl eher Port 465 sein!?
Oder Ihr nutzt TLS auf Port 25(/587?).
HTH
Alfred
P.S.:
# Ui, irgendwie habe ich jetzt den Anschluss verloren und keinen Beitrag
# mit einer Art Zusammenfassung gefunden.
RTFM
http://zielgra.de/hamster/HAMSTER_HLP_DE.ZIP
-> "Hamster und SSL"
--
09198.7
Wolfgang Bauer
> Es schrieb einmal Jens Weissenburger:
>> Ah, OK ... ohne TLS ... einfach nur den Port ändern, gegenüber der
>> bisherigen Methode. Damit geht's jetzt zumindest.
> Klar. Dann geht das Passwort aber unverschlüsselt über die Leitung.
Ich benutze TLS und das ist in den SMTP Einstellungen so eingetragen.
Meinst Du das reicht nicht beim Senden, oder weiß der Hamster bei Port
587 daß die Verschlüsselung dann TLS ist?
In den Einstellungshinweisen von GMX steht -
| Als SMTP-Port kann hier alternativ (nach RFC 2476) auch SMTP-Port 587
| verwendet werden.
Jens Weissenburger
> Für SSL müsste es wohl eher Port 465 sein!?
Danke, mit diesem Port geht bei mir jetzt auch
ControlRunSendMailAuthTLS fehlerfrei durch.
Gruß, Jens
Alfred Peters
> Alfred Peters wrote:
>> Es schrieb einmal Jens Weissenburger:
>
>>> Ah, OK ... ohne TLS ... einfach nur den Port ändern, gegenüber der
>>> bisherigen Methode. Damit geht's jetzt zumindest.
>> Klar. Dann geht das Passwort aber unverschlüsselt über die Leitung.
>
> Ich benutze TLS und das ist in den SMTP Einstellungen so eingetragen.
> Meinst Du das reicht nicht beim Senden,
Das reicht nicht beim Senden über das Skript. Dort muss SSLMode extra
gesetzt werden.
> oder weiß der Hamster bei Port
> 587 daß die Verschlüsselung dann TLS ist?
Nein, dem Hamster ist egal welchen Port Du einstellst - solange dort ein
Server antwortet.
> In den Einstellungshinweisen von GMX steht -
>
>| Als SMTP-Port kann hier alternativ (nach RFC 2476) auch SMTP-Port 587
>| verwendet werden.
Mit TLS, SSL oder ohne Verschlüsselung? Vermutlich ohne, vielleicht noch
TLS aber eben kein SSL.
Alfred
--
09199.1
Wolfgang Bauer
> Es schrieb einmal Wolfgang Bauer:
>> Ich benutze TLS und das ist in den SMTP Einstellungen so eingetragen.
>> Meinst Du das reicht nicht beim Senden,
> Das reicht nicht beim Senden über das Skript. Dort muss SSLMode extra
> gesetzt werden.
Und wie müßte das dann im Scriptstehen? (Die Hamsterhilfe kann ich hier
in Windows 7 leider nicht ansehen. Da hilft auch WinHlp32.exe nicht)
HamSendMailAuth( "mail.gmx.net","587","$1" )
HamSendMailAuth( "mail.gmx.net","SMTPS","$1" )
> Mit TLS, SSL oder ohne Verschlüsselung? Vermutlich ohne, vielleicht noch
> TLS aber eben kein SSL.
Du meinst "vielleicht noch SSL aber eben kein TSL"?
,--[ Wikipedia ]
¦ TLS 1.0, 1.1 und 1.2 sind die standardisierten Weiterentwicklungen von
¦ SSL 3.0 (TLS 1.0 steht neu für SSL 3.1). SSL wird also nun unter dem
¦ Namen TLS weiterentwickelt.
¦
¦ Von der Verwendung des SMTPS- wird zugunsten des neueren
¦ STARTTLS-Verfahrens, welches keinen eigenen Port benötigt, abgeraten.
¦ Deshalb wird auch für SMTPS der Port 465 nicht mehr in der Liste der
¦ well-known-Ports der IANA geführt. Die Nutzung des Verfahrens sowie
¦ dieses Ports ist dennoch noch weit verbreitet.
`----
STARTTLS kann der Hamster sicher noch nicht, oder?
Wolfgang Jäth
> Ui, irgendwie habe ich jetzt den Anschluss verloren und keinen Beitrag
> mit einer Art Zusammenfassung gefunden. Ich habe vom GMX noch keine
> Nachricht, würde aber gern vorbereitet sein ;)
Tja, das mit den Benachrichtigungen scheint bei denen irgendwie komplett
durcheinander zu gehen. Anscheinend benachrichtigen die, wen sie wollen, und
nicht, wen es betrifft. Falls es /überhaupt/ jemanden betrifft; soweit ich
das sehe, ist zumindest /hier/ niemand.
> Im Script frage ich derzeit so ab:
> $Hamster->ControlRunFetchMail("pop.gmx.de", "pop3", "\$2", "", "GMX");
> Was muss ich daran ändern und was im Hamster?
Der Umstellungstermin war angeblich der 10.03. wenn Du also /immer/ noch
Deine Emails dort abholen kannst, dann musst Du im Prinzip vermutlich /gar/
nix tun.
Aber prophylaktisch kannst Du natürlich trotzdem auf SSL umstellen. Dazu
musst Du Dir die SSL-Dateien besorgen (siehe
<gp0id7...@stefan.msgid.phost.de>), und den Fetchmail-Aufruf ändern:
Statt "POP3" musst Du "995"[1] als Port angeben, und als 8. Parameter aka
SSL die '1' (als Integer, d.h. ohne Hochkommas).
[1] Du kannst auch 'pop3s 995/tcp' in die
'C:\windows\system32\drivers\etc\services' eintragen (sofern noch nicht
vorhanden), und dann diesen Portnamen verwenden
Wolfgang
--
Heiko Studt
> STARTTLS kann der Hamster sicher noch nicht, oder?
Sollte er können.
Wolfgang Bauer
> Am 14.03.2009 schrieb Wolfgang Bauer:
>> STARTTLS kann der Hamster sicher noch nicht, oder?
> Sollte er können.
Mit den dll's die ich hier habe scheinbar nicht. Es steht nur SSL/TSL
zur Auswahl.
http://www.wolfgang-bauer.at/screenshot/starttls.jpg
Alfred Peters
betroffen?
Es schrieb einmal Wolfgang Bauer:
> Alfred Peters wrote:
>> Das reicht nicht beim Senden über das Skript. Dort muss SSLMode extra
>> gesetzt werden.
>
> Und wie müßte das dann im Scriptstehen? (Die Hamsterhilfe kann ich hier
> in Windows 7 leider nicht ansehen. Da hilft auch WinHlp32.exe nicht)
Ich meine, man kann sie sich unter Linux anschauen. - SCNR
# HamSendMailAuth( <server>, <port>, <user>, <pass>, <from-select>,
# <to-select>, <SSLMode>, <SSLVerify>, <SSLCaFile> )
# Startet einen Auftrag zum Senden der E-Mails zu einem SMTP-Server unter
# Benutzung des SMTP-Auth-Verfahrens. Als Parameter für den Usernamen
# kann auch eine Variable (z.B. $42) verwendet werden, welche auf den
# Usernamen und das Passwort im internen Passwortspeicher des Hamsters
# verweißt. Ist der Parameter from-select oder to-select nicht leer,
# werden nur E-Mails versendet, deren Envelope-From bzw. Rcpt-To dem
# regulären Ausdruck in diesem Parameter entspricht.
#
# <SSLMode> gibt an, ob und wie SSL/TLS verwendet wird:
# 0 - SSL/TLS abgeschaltet # 1 - SSL auf separatem Port (sPOP3 bzw,sSMTP)
# 2 - TLS, wenn möglich # 3 - TLS wird erzwungen
#
# <SSLVerify> regelt die Überprüfung der fremden Server-Zertifikate:
# 0 - Zertifikatsüberprüfung abgeschaltet
# 1 - Zertifikatsüberprüfung, falls Zertifikat vorgelegt
# 2 - Zertifikatsüberprüfung immer
# 3 - Zertifikatsüberprüfung immer und Vergleich des Serverzertifikats
# mit lokaler Kopie
>> Mit TLS, SSL oder ohne Verschlüsselung? Vermutlich ohne, vielleicht noch
>> TLS aber eben kein SSL.
>
> Du meinst "vielleicht noch SSL aber eben kein TSL"?
Nein.
> ,--[ Wikipedia ]
> ¦ TLS 1.0, 1.1 und 1.2 sind die standardisierten Weiterentwicklungen von
> ¦ SSL 3.0 (TLS 1.0 steht neu für SSL 3.1). SSL wird also nun unter dem
> ¦ Namen TLS weiterentwickelt.
> ¦
> ¦ Von der Verwendung des SMTPS- wird zugunsten des neueren
> ¦ STARTTLS-Verfahrens, welches keinen eigenen Port benötigt, abgeraten.
> ¦ Deshalb wird auch für SMTPS der Port 465 nicht mehr in der Liste der
> ¦ well-known-Ports der IANA geführt. Die Nutzung des Verfahrens sowie
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ¦ dieses Ports ist dennoch noch weit verbreitet.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also SMTP:
Verschlüsselung: | Port
----------------------------
ohne | 25 / 587
TLS | 25 / 587
SSL | 465
> STARTTLS kann der Hamster sicher noch nicht, oder?
Klar kann er das.
Alfred
--
09200.7
Alfred Peters
>> Am 14.03.2009 schrieb Wolfgang Bauer:
>
>>> STARTTLS kann der Hamster sicher noch nicht, oder?
>> Sollte er können.
>
> Mit den dll's die ich hier habe scheinbar nicht. Es steht nur SSL/TSL
> zur Auswahl.
STARTTLS gehört zu TLS.
Alfred
--
09200.7
Wolfgang Bauer
> STARTTLS gehört zu TLS.
Mein Mailclient The Bat! in der Version 4.1.11 kennt
SMTP
Verbindung: Standard Port 25
Verbindung: Geschützt auf Standard-Port(STARTTSL)
Verbindung: Geschützt auf dezidiertem Port 465
POP
Verbindung: Standard Port 110
Verbindung: Geschützt auf Standard-Port(STARTTSL)
Verbindung: Geschützt auf dezidiertem Port 995
Demnach entspricht STARTTSL im Hamster
SSL/TSL immer nutzen (Standardport)?
Wolfgang Bauer
> Mal 'ne Frage am Rande: Ist SMTP-Auth überhaupt von dem "GMX-Problem"
> betroffen?
Ich verstehe das so.
,--
¦ Nach der Umstellung am 16.3.2009 kann Ihr Mailprogramm Sie nicht mehr an
¦ unseren Mailservern anmelden, wenn die Optionen "APOP" oder "CRAM-MD5"
¦ ^^^^^^^^^^^
¦ aktiviert sind. Bitte entfernen Sie ggf. die Einstellungen für diese
¦ Optionen und wählen Sie stattdessen "SSL" oder "TLS" als sichere
¦ Verbindung!
`----
> HamSendMailAuth( <server>, <port>, <user>, <pass>, <from-select>, <to-select>, <SSLMode>, <SSLVerify>, <SSLCaFile> )
Dementsprechend habe ich die Scriptzeile so zusammengestellt.
HamSendMailAuth("mail.gmx.net", "465", "$1", "", "", "", "1", "0", "0")
Das sollte dann passen.
Alfred Peters
>
>> STARTTLS gehört zu TLS.
> Demnach entspricht STARTTSL im Hamster
> SSL/TSL immer nutzen (Standardport)?
Ja.
Alfred
--
09200.9
Alfred Peters
> Alfred Peters wrote:
>> HamSendMailAuth( <server>, <port>, <user>, <pass>, <from-select>, <to-select>, <SSLMode>, <SSLVerify>, <SSLCaFile> )
>
> Dementsprechend habe ich die Scriptzeile so zusammengestellt.
> HamSendMailAuth("mail.gmx.net", "465", "$1", "", "", "", "1", "0", "0")
>
> Das sollte dann passen.
Nein. Bei <SSLCaFile> kann man eine Datei mit dem CA-Zertifikat für den
Server angeben. Da das optional ist lass den Parameter weg.
HamSendMailAuth("mail.gmx.net", "465", "$1", "", "", "", "1", "0")
Alfred
--
09200.9
Wolfgang Bauer
> Bei <SSLCaFile> kann man eine Datei mit dem CA-Zertifikat für den
> Server angeben. Da das optional ist lass den Parameter weg.
> HamSendMailAuth("mail.gmx.net", "465", "$1", "", "", "", "1", "0")
In Ordnung, ich bedanke mich.
Jens Weissenburger
> [1] Du kannst auch 'pop3s 995/tcp' in die
> 'C:\windows\system32\drivers\etc\services' eintragen (sofern noch
> nicht vorhanden), und dann diesen Portnamen verwenden
Das "Fetchen" funktioniert. Beim Senden verwende ich jetzt Port 465.
Der steht nicht in der services-Datei drin. Es funktioniert aber.
Gruß, Jens
Wolfgang Jäth
>> 'C:\windows\system32\drivers\etc\services' eintragen (sofern noch
>> nicht vorhanden), und dann diesen Portnamen verwenden
>
> Das "Fetchen" funktioniert. Beim Senden verwende ich jetzt Port 465.
> Der steht nicht in der services-Datei drin. Es funktioniert aber.
Muss auch nicht; die services ist nur eine Übersetzungstabelle für
Port*namen* zu den entsprechenden Nummern.
Wolfgang
--
Alfred Peters
> Mal 'ne Frage am Rande: Ist SMTP-Auth überhaupt von dem "GMX-Problem"
> betroffen?
Ja Ingrid, ist es.
Hier[1] habe ich ein Log gefunden:
| SMTP<< 250-mail.gmx.net GMX Mailservices
| 250-8BITMIME
| 250-ENHANCEDSTATUSCODES
| 250-SIZE
| 250-AUTH=LOGIN PLAIN
| 250-AUTH LOGIN PLAIN
| 250 STARTTLS
Es wird nur noch LOGIN und PLAIN angeboten.
Alfred
[1] <slrngrqur...@eene.mine.nu>
--
09203.8
Heiko Studt
> Aber dann kam die Überraschung. Nachdem ja laut GMX CRAM-MD5 nicht mehr
> funktioniert habe ich im Hamster umgestellt auf CRAM-SHA1 und alle
> anderen Optionen deaktiviert gelassen.(so hatte ich es auch bisher
> eingestellt) Dann wollte ich probehalber ein mail versenden - was
> passiert?:
GMX bietet kein CRAM-SHA1 an. CRAM-MD5 wohl auch nicht mehr bzw. nur
noch manchmal oder so.
Nutze einfach SSL, das ist ja glücklicherweise relativ einfach
einrichtbar.
Willi Bornemann
> Am 10.03.2009 schrieb Willi Bornemann:
>
>> Aber dann kam die Überraschung. Nachdem ja laut GMX CRAM-MD5 nicht
>> mehr funktioniert habe ich im Hamster umgestellt auf CRAM-SHA1 und
>> alle anderen Optionen deaktiviert gelassen.(so hatte ich es auch
>> bisher eingestellt) Dann wollte ich probehalber ein mail versenden -
>> was passiert?:
>
> GMX bietet kein CRAM-SHA1 an. CRAM-MD5 wohl auch nicht mehr bzw. nur
> noch manchmal oder so.
Mittlerweile hab ich PLAIN eingestellt, das funktioniert.
> Nutze einfach SSL, das ist ja glücklicherweise relativ einfach
> einrichtbar.
Ja danke, hab ich mittlerweile eingerichtet.
Gruß Willi