Problem bei Login auf Dovecot IMAP Server
Simon Bienlein
auf meinem Server möchte ich Postfix und Dovecot installieren. Es soll
nur ein virtueller Benutzer (vmail) existieren. Beim Testen meiner
Anmeldung am IMAP-Dovecot Server habe ich ein Problem. Wenn ich mich via
telnet vom Server aus einlogge, funktioniert es. Der Loginversuch vom
entfernten Client schlägt fehl:
* OK Dovecot ready.
1 login si...@host.dyndns.org geheim
* BAD [ALERT] Plaintext authentication is disabled, but your client sent
password in plaintext anyway. If anyone was listening, the password was
exposed.
1 NO Plaintext authentication disabled.
2 logout
* BYE Logging out
2 OK Logout completed.
Warum funktioniert das plaintext Login von localhost des Servers aus und
vom entfernten Client nicht? Wie muss ich mich vom entfernten PC aus
einloggen? Thunderbird kann mit dem IMAP-Server auch nicht kommunizieren
und behauptet, dass dies kein IMAP-Server wäre.
Hier die Ausgabe von dovecot -n:
# /etc/dovecot/dovecot.conf
log_timestamp: %Y-%m-%d %H:%M:%S
protocols: imap
login_dir: /var/run/dovecot/login
login_executable: /usr/lib/dovecot/imap-login
mail_privileged_group: mail
mail_location: maildir:/home/vmail/%d/%n
auth default:
mechanisms: plain login
verbose: yes
passdb:
driver: passwd-file
args: /etc/dovecot/passwd
userdb:
driver: static
args: uid=vmail gid=vmail home=/home/vmail/%d/%n allow_all_users=yes
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 384
user: vmail
In der Datei /etc/dovecot/passwd stehen die Passwörter im Klartext.
Vielen Dank im Voraus für eure Hilfe.
Gruß
Simon
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Jochen Schulz
>
> auf meinem Server möchte ich Postfix und Dovecot installieren. Es soll
> nur ein virtueller Benutzer (vmail) existieren. Beim Testen meiner
> Anmeldung am IMAP-Dovecot Server habe ich ein Problem. Wenn ich mich via
> telnet vom Server aus einlogge, funktioniert es. Der Loginversuch vom
> entfernten Client schlägt fehl:
Generell: auth_debug=yes. Aber die Meldung vom Server ist ja eindeutig.
> * OK Dovecot ready.
> 1 login si...@host.dyndns.org geheim
> * BAD [ALERT] Plaintext authentication is disabled, but your client sent
> password in plaintext anyway. If anyone was listening, the password was
> exposed.
> 1 NO Plaintext authentication disabled.
> 2 logout
> * BYE Logging out
> 2 OK Logout completed.
Du mußt Deinem ungenannten Client halt abgewöhnen, die Authentifizierung
per Plaintext abzugewöhnen.
> Warum funktioniert das plaintext Login von localhost des Servers aus und
> vom entfernten Client nicht?
Weil Dovecot localhost als vertrauenswürdig erachtet, andere Netze aber
nicht.
> Wie muss ich mich vom entfernten PC aus
> einloggen? Thunderbird kann mit dem IMAP-Server auch nicht kommunizieren
> und behauptet, dass dies kein IMAP-Server wäre.
Komisch. Spiel mal mit den Authentifizierungsoptionen herum.
J.
--
The houses of parliament make me think of school bullies.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Michael Windelen
> Hallo zusammen,
>
> auf meinem Server möchte ich Postfix und Dovecot installieren. Es soll
> nur ein virtueller Benutzer (vmail) existieren. Beim Testen meiner
> Anmeldung am IMAP-Dovecot Server habe ich ein Problem. Wenn ich mich via
> telnet vom Server aus einlogge, funktioniert es. Der Loginversuch vom
> entfernten Client schlägt fehl:
>
> * OK Dovecot ready.
> 1 login si...@host.dyndns.org geheim
Ich glaub hier steht die Lösung:
> * BAD [ALERT] Plaintext authentication is disabled, but your client sent
> password in plaintext anyway. If anyone was listening, the password was
> exposed.
> 1 NO Plaintext authentication disabled.
Dazu steht in der original Config bei mir:
# Disable LOGIN command and all other plaintext authentications unless
# SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP
# matches the local IP (ie. you're connecting from the same computer), the
# connection is considered secure and plaintext authentication is allowed.
#disable_plaintext_auth = yes
Also die Variable entsprechend ändern:
disable_plaintext_auth = no
dovecot neustarten und dann nochmal probieren.
Grüße
Michael
--
Bitte kein Cc an mich, ich lese die Liste.
Simon Bienlein
> Du mußt Deinem ungenannten Client halt abgewöhnen, die Authentifizierung
> per Plaintext abzugewöhnen.
ich testete zunächst mit telnet. Wenn man es richtig macht, sollte man
sich damit ja auch anmelden können.
>> Warum funktioniert das plaintext Login von localhost des Servers aus und
>> vom entfernten Client nicht?
>
> Weil Dovecot localhost als vertrauenswürdig erachtet, andere Netze aber
> nicht.
Das habe ich mir schon gedacht. Doch über welches Verfahren kann ich
mich dann via telnet vom entfernten Netzwerk einloggen?
Simon Bienlein
> Ich glaub hier steht die Lösung:
>
>> * BAD [ALERT] Plaintext authentication is disabled, but your client sent
>> password in plaintext anyway. If anyone was listening, the password was
>> exposed.
>> 1 NO Plaintext authentication disabled.
>
> Dazu steht in der original Config bei mir:
>
> # Disable LOGIN command and all other plaintext authentications unless
> # SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP
> # matches the local IP (ie. you're connecting from the same computer), the
> # connection is considered secure and plaintext authentication is allowed.
> #disable_plaintext_auth = yes
>
> Also die Variable entsprechend ändern:
>
> disable_plaintext_auth = no
vielen Dank für deine Antwort.
Ja, mit dieser Einstellung kann man sich dann auch vom entfernten Netz
via plaintext einloggen. doch wie hätte ich mich sonst anmelden müssen?
Habe im RFC 3501 gelesen, dass es neben dem Befehl LOGIN noch das
Kommando AUTHENTICATE gibt. Evtl. schaffe ich es auf diesem Weg noch,
mich ohne plaintext zunächst per telnet einzuloggen.
Gruß
Simon
1. <http://www.faqs.org/rfcs/rfc3501.html>
Michael Windelen
Simon Bienlein schrieb:
>
> vielen Dank für deine Antwort.
> Ja, mit dieser Einstellung kann man sich dann auch vom entfernten Netz
> via plaintext einloggen. doch wie hätte ich mich sonst anmelden müssen?
> Habe im RFC 3501 gelesen, dass es neben dem Befehl LOGIN noch das
> Kommando AUTHENTICATE gibt. Evtl. schaffe ich es auf diesem Weg noch,
> mich ohne plaintext zunächst per telnet einzuloggen.
>
> Gruß
> Simon
> 1. <http://www.faqs.org/rfcs/rfc3501.html>
>
>
Ich würde ssl einschalten (pops imaps) und pop und imap nicht mehr zulassen.
disable_plaintext_auth würde ich wieder auf yes setzen.
So kannst du von überall sicher deine eMails per ssl abrufen.
Zum testen auf der Console:
openssl s_client -connect $HOST:$PORT
VG
Michael
PS: Bitte Signatur beachten, kein Cc an mich, ich lese die Liste. Danke!
--
Bitte kein Cc an mich, ich lese die Liste.
Manfred Schmitt
>
> vielen Dank für deine Antwort.
> Ja, mit dieser Einstellung kann man sich dann auch vom entfernten Netz
> via plaintext einloggen. doch wie hätte ich mich sonst anmelden müssen?
> Habe im RFC 3501 gelesen, dass es neben dem Befehl LOGIN noch das
> Kommando AUTHENTICATE gibt. Evtl. schaffe ich es auf diesem Weg noch,
> mich ohne plaintext zunächst per telnet einzuloggen.
>
Und wech,
Manne
Simon Bienlein
Am 20.11.2008 17:22, Michael Windelen schrieb:
> Ich würde ssl einschalten (pops imaps) und pop und imap nicht mehr zulassen.
> disable_plaintext_auth würde ich wieder auf yes setzen.
> So kannst du von überall sicher deine eMails per ssl abrufen.
>
> Zum testen auf der Console:
>
> openssl s_client -connect $HOST:$PORT
vielen Dank für diesen Hinweis. SSL werde ich erst einrichten, wenn ich
ein paar Fragen dazu geklärt habe. Ich möchte nämlich kein
selbstsigniertes Zertifikat verwenden. Voraussetzung wäre aber, dass ich
ein gekauftes Zertifikat nicht nur für Mail, sondern auch für den Apache
und OpenVPN verwenden kann. Ist das möglich oder brauche ich für jeden
Service ein eigenes Zertifikat? Wenn ich alle Dienste unter dem Host
www.meinedomain.de betreibe, passen DNS-Eintrag und IP Adresse doch
immer zusammen.
Unter www.psw.net habe ich nichts darüber gelesen, dass man für
verschiedene dienste jeweils eigene Zertifikate erstellen muss. Die
Zertifizierungsanfrage sollte ja immer identisch sein.
Viele Grüße
Simon
Simon Bienlein
Am 20.11.2008 17:23, Manfred Schmitt schrieb:
> Simon Bienlein schrieb:
>>
>> vielen Dank für deine Antwort.
>> Ja, mit dieser Einstellung kann man sich dann auch vom entfernten Netz
>> via plaintext einloggen. doch wie hätte ich mich sonst anmelden müssen?
>> Habe im RFC 3501 gelesen, dass es neben dem Befehl LOGIN noch das
>> Kommando AUTHENTICATE gibt. Evtl. schaffe ich es auf diesem Weg noch,
>> mich ohne plaintext zunächst per telnet einzuloggen.
>>
> Ich glaub Du suchst imtest aus cyrus-clients-2.2.
vielen Dank für deine Antwort. Dieses Paket benötige ich IMHO nur, wenn
ich SSL verwende, oder? Vorerst bin ich mit der unverschlüsselten
Verbindung einverstanden. Bei GMX verwende ich aktuell auch keine
Verschlüsselung. Wenn ich aber nach und nach auf meinen eigenen
Mailserver umstelle, kann ich das aber implementieren.
Gruß Simon
Michael Windelen
> vielen Dank für deine Antwort. Dieses Paket benötige ich IMHO nur, wenn
> ich SSL verwende, oder? Vorerst bin ich mit der unverschlüsselten
> Verbindung einverstanden. Bei GMX verwende ich aktuell auch keine
> Verschlüsselung. Wenn ich aber nach und nach auf meinen eigenen
> Mailserver umstelle, kann ich das aber implementieren.
>
Man sollte dann zumindest eine andere Authentifizierungsmethode als
klartext einstellen wenn man kein ssl benutzt. Alles andere ist in
meinen Augen grob fahrlässig. (Man könnte dein Passwort einfach auslesen
und dann deinen Mailserver, sofern du auch Versand per smtp anbietest,
als SPAM-Schleuder mißbrauchen.)
Grüße
Michael
PS: Leider kann ich dir bei den Zertifikaten nicht helfen da ich
selbstsignierte benutze, reicht mir privat ;)
--
Bitte kein Cc an mich, ich lese die Liste.
Martin Reising
> Voraussetzung wäre aber, dass ich ein gekauftes Zertifikat nicht nur
> für Mail, sondern auch für den Apache und OpenVPN verwenden kann.
Kaufen muß nicht umbedingt sein: https://www.cacert.org
Für OpenVPN reicht eine eigene CA, wie in
/usr/share/doc/openvpn/examples/easy-rsa
beschrieben/dokumentiert.
> Ist das möglich oder brauche ich für jeden Service ein eigenes
> Zertifikat?
Es reicht ein Zertifikat pro FQDN (CN), man kann auch mehrere FQDN in
einem Zertifikat haben (CN+SubjAltNames). Ob das abseits von HTTPS
funktioniert oder eine Rolle spielt ist leider aus
http://wiki.cacert.org/wiki/VhostTaskForce
für mich nicht so recht ersichtlich.
--
Nicht Absicht unterstellen, wenn auch Dummheit ausreicht!
Stefan Bauer
> Kaufen muß nicht umbedingt sein: https://www.cacert.org
Cacert ist schon ganz nett, solange das Root-CA Zertifikat nicht in
allen Browsern landet aber wenig interessant.
Gruß
--
stefan...@cubewerk.de Cubewerk
Tel +49 8621 996 02 37 IT-Beratung + Planung
Tel +49 179 119 47 67 Verkauf von Hard und Software
Fax +49 1212 511057903 Herzog-Otto-Straße 32
http://www.cubewerk.de 83308 Trostberg
Simon Bienlein
> Man sollte dann zumindest eine andere Authentifizierungsmethode als
> klartext einstellen wenn man kein ssl benutzt. Alles andere ist in
> meinen Augen grob fahrlässig. (Man könnte dein Passwort einfach auslesen
> und dann deinen Mailserver, sofern du auch Versand per smtp anbietest,
> als SPAM-Schleuder mißbrauchen.)
vielen Dank für deine Antwort. Ich habe das gerade einmal geprüft und z.
b. bei meinem GMX-Account festgestellt, dass man sich auch im Klartext
via telnet am POP3-Server anmelden kann. Am SMTP-Server konnte ich mich
via PLAIN (base64 String) authentifizieren, was ja auch unsicher ist, da
der String ja problemlos decodiert werden kann.
Um es dann wenigstens selbst besser zu machen, habe ich den Dovecot auf
CRAM-MD5 umgestellt.
Warum verwenden Mail-Anbieter nicht wenigstens CRAM-MD5, was ja - laut
Wikipedia - doch recht sicher ist. Jedenfalls sicherer als echter
Klartext oder Base64. Wenn eine Privatperson einen unsicheren Mailserver
betreibt ist das eine Sache, aber die großen Unternehmen sollten es doch
echt besser wissen.
Gruß Simon
Michael Windelen
> Warum verwenden Mail-Anbieter nicht wenigstens CRAM-MD5, was ja - laut
> Wikipedia - doch recht sicher ist. Jedenfalls sicherer als echter
> Klartext oder Base64. Wenn eine Privatperson einen unsicheren Mailserver
> betreibt ist das eine Sache, aber die großen Unternehmen sollten es doch
> echt besser wissen.
Eigentlich ja, das sollten sie!
Allerdings, wir wollen ja auch keine teureren Produkte verkaufen mit
denen das dann möglich ist...
Aber CRAM-MD5 oder ssl bzw. tls sollten die schon anbieten und klartext
etc. nicht mehr erlauben, auch wenn es mehr Rechenleistung erfordert.
Dafür halten sie sich so die Kundschaft vom leibe die die Fehlermeldung
des MUA nicht deuten wollen (können) wenn so sachen wie
Klartextauthentifizierung nicht mehr erlaubt sind...
Grüße
Michael
--
Bitte kein Cc an mich, ich lese die Liste.
Reinhold Plew
> Simon Bienlein schrieb:
>
>> Warum verwenden Mail-Anbieter nicht wenigstens CRAM-MD5, was ja - laut
>> Wikipedia - doch recht sicher ist. Jedenfalls sicherer als echter
>> Klartext oder Base64. Wenn eine Privatperson einen unsicheren
>> Mailserver betreibt ist das eine Sache, aber die großen Unternehmen
>> sollten es doch echt besser wissen.
>
> Eigentlich ja, das sollten sie!
> Allerdings, wir wollen ja auch keine teureren Produkte verkaufen mit
> denen das dann möglich ist...
Welche teuren Produkte?
> Aber CRAM-MD5 oder ssl bzw. tls sollten die schon anbieten und klartext
> etc. nicht mehr erlauben, auch wenn es mehr Rechenleistung erfordert.
> Dafür halten sie sich so die Kundschaft vom leibe die die Fehlermeldung
> des MUA nicht deuten wollen (können) wenn so sachen wie
> Klartextauthentifizierung nicht mehr erlaubt sind...
Schön formuliert ;-)
Aber genauso ist es, sobald man mehr als nur den Mailserver eingeben
muss, wird es schon für so manchen User schwierig.
Aber SSL bzw. TLS wird ja von fast allen Betreibern angeboten, es muss
nur genutzt werden. Da sollte eine mögliche Klartextauthentifizierung
kein Problem darstellen; Dafür wird ja das Klartextpasswort benötigt,
was ja keiner mehr sieht.
Reinhold
Michael Windelen
>
> Welche teuren Produkte?
Die ohne Werbung und mit IMAP :)
GMX Promail, TopMail
bei web.de ähnlich.
Knapp 5€ im Monat finde ich für ein "bisschen" email schon teuer... ok,
es gibt Zusatzleistungen wie 100 SMS.
Ich muß dir jedoch recht geben, zumindest gmx erlaubt ssl bei den
kostenlosen Konten (mußte mir erstmal eins gerade anlegen zum testen :)
Leider geht das immer noch nicht wenn man über das Webinterface geht...
Anmelden per https://gmx.net/de geht, danach ist aber Alles wieder http.
Hatte ich letztens bei einem Freund bemerkt, daher dann auch erst die
Annahme dass das auch für pop etc. gilt. Mein Fehler... Da hab ich wohl
erst zuviel geflucht und verteufelt! Gelobe Besserung! :)
Grüße
Michael
Reinhold Plew
Michael Windelen wrote:
> Reinhold Plew schrieb:
>>
>> Welche teuren Produkte?
> Die ohne Werbung und mit IMAP :)
>
> GMX Promail, TopMail
> bei web.de ähnlich.
> Knapp 5€ im Monat finde ich für ein "bisschen" email schon teuer... ok,
> es gibt Zusatzleistungen wie 100 SMS.
Nungut, wer solche Provider nutzt, muss wissen was er tut.
> Ich muß dir jedoch recht geben, zumindest gmx erlaubt ssl bei den
> kostenlosen Konten (mußte mir erstmal eins gerade anlegen zum testen :)
> Leider geht das immer noch nicht wenn man über das Webinterface geht...
> Anmelden per https://gmx.net/de geht, danach ist aber Alles wieder http.
> Hatte ich letztens bei einem Freund bemerkt, daher dann auch erst die
> Annahme dass das auch für pop etc. gilt. Mein Fehler... Da hab ich wohl
> erst zuviel geflucht und verteufelt! Gelobe Besserung! :)
IMHO reden wir hier ja über die gesicherte Anmeldung, oder?
Obwohl, viele Anbieter sagen da ja: Wenn Du eine sichere Anmeldung haben
möchstest, dann musst Du dafür zusätzlich bezahlen.
Aber De Facto kostet es den Anbieter ja nicht wirkllich mehr, diesen
'Service' zur Verfügung zu stellen.
Wenn man nicht das Webinterface benutzt, ist auch die Übertragung der
Mail verschlüsselt.
Aber die meisten User benutzen halt das Webinterface, weil so Sachen wie
Outlook halt Geld kosten.
Und da ist halt Aufklärung nötig. Benutze Open Source und auch die
EMails werden verschlüsselt übertragen.
Doch diese Diskussion hat nichts mehr mit Debian zu tun, das ist etwas
ganz Grundsätzliches.
Reinhold
Simon Bienlein
Am 25.11.2008 22:58, Michael Windelen schrieb:
> Reinhold Plew schrieb:
>>
>> Welche teuren Produkte?
> Die ohne Werbung und mit IMAP :)
>
> GMX Promail, TopMail
> bei web.de ähnlich.
> Knapp 5€ im Monat finde ich für ein "bisschen" email schon teuer... ok,
> es gibt Zusatzleistungen wie 100 SMS.
>
> Ich muß dir jedoch recht geben, zumindest gmx erlaubt ssl bei den
> kostenlosen Konten (mußte mir erstmal eins gerade anlegen zum testen :)
vermutlich wird SSL aber von den wenigsten Kunden verwendet. Das liegt
aber nicht an der fehlenden unterstützung des Clients, sondern daran,
dass man standardmäßig nicht dazu gezwungen wird. Wenn man sich durch
die Assistenten klickt, wird IMHO unverschlüsselt eingerichtet und es
funktioniert ja auch. Daher habe auch ich bisher ohne Verschlüsselung
meine Zugangsdaten übertragen ...
Gruß Simon
Simon Bienlein
Am 25.11.2008 23:24, Reinhold Plew schrieb:
> IMHO reden wir hier ja über die gesicherte Anmeldung, oder?
> Obwohl, viele Anbieter sagen da ja: Wenn Du eine sichere Anmeldung haben
> möchstest, dann musst Du dafür zusätzlich bezahlen.
> Aber De Facto kostet es den Anbieter ja nicht wirkllich mehr, diesen
> 'Service' zur Verfügung zu stellen.
das sehe ich auch so. Aber standardmäßig wird eben auch in den
Assistenten der Clients von keiner Verschlüsselung ausgegangen.
> Aber die meisten User benutzen halt das Webinterface, weil so Sachen wie
> Outlook halt Geld kosten.
>
> Und da ist halt Aufklärung nötig. Benutze Open Source und auch die
> EMails werden verschlüsselt übertragen.
>
> Doch diese Diskussion hat nichts mehr mit Debian zu tun, das ist etwas
> ganz Grundsätzliches.
Daher würde ich es auch erst mal dabei belassen. ich glaube aber, dass
auch Outlook Express mit Verschlüsselung umgehen kann, wenn man es
entsprechend aktiviert. Ich weiß aber auch nicht, welches Verfahren
Outlook selbstständig mit dem Mailserver aushandelt. Vielleicht ja doch
auch CRAM-MD5. Wenn ich mich einmal mit Netzwerksniffern für mein
lokales netz beschäftige, kann ich das ja evtl. herausfinden. Wäre ja
super, wenn wenigstens CRAM-MD5 verwendet werden würde. Dann wäre die
Aufregung auch nicht mehr so groß - von der unverschlüsselten Mail an
sich einmal abgesehen.
Gruß Simon
Jochen Schulz
>
> IMHO reden wir hier ja über die gesicherte Anmeldung, oder?
> Obwohl, viele Anbieter sagen da ja: Wenn Du eine sichere Anmeldung haben
> möchstest, dann musst Du dafür zusätzlich bezahlen.
> Aber De Facto kostet es den Anbieter ja nicht wirkllich mehr, diesen
> 'Service' zur Verfügung zu stellen.
Doch, das ist in den Größenordnungen von GMX & Co schon relevant, weil
die deutlich mehr Hardware für ihre 10 Millionen Kunden bräuchten, die
alle zwanzig Minuten (oder wie oft auch immer es zugelassen wird)
pollen.
J.
--
If I am asked 'How are you' more than a million times in my life I
promise to explode.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Jochen Schulz
>
> Daher würde ich es auch erst mal dabei belassen. ich glaube aber, dass
> auch Outlook Express mit Verschlüsselung umgehen kann, wenn man es
> entsprechend aktiviert. Ich weiß aber auch nicht, welches Verfahren
> Outlook selbstständig mit dem Mailserver aushandelt. Vielleicht ja doch
> auch CRAM-MD5.
Ist jetzt schon ein paar Jahre her, aber als ich mir mal angeguckt hab,
was in meiner FH alles über das unverschlüsselte WLAN geht... sagen wir,
es war erschreckend, wie wenig Problembewußtsein unter meinen
Kommolitonen (Fach Wirtschaftsinformatik) vorhanden war. Und ihre
Software hat ihnen nicht gerade geholfen.
J.
--
I feel yawning hollowness whilst talking to people at parties.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Paul Muster
> Reinhold Plew:
>> IMHO reden wir hier ja über die gesicherte Anmeldung, oder?
>> Obwohl, viele Anbieter sagen da ja: Wenn Du eine sichere Anmeldung haben
>> möchstest, dann musst Du dafür zusätzlich bezahlen.
>> Aber De Facto kostet es den Anbieter ja nicht wirkllich mehr, diesen
>> 'Service' zur Verfügung zu stellen.
>
> Doch, das ist in den Größenordnungen von GMX & Co schon relevant, weil
> die deutlich mehr Hardware für ihre 10 Millionen Kunden bräuchten, die
> alle zwanzig Minuten (oder wie oft auch immer es zugelassen wird)
> pollen.
Das regelmäßige Pollen läuft i.A. über POP3, nicht über HTTP. Und bei
POP3 ist auch in den FreeMail-Accounts SSL verfügbar.
mfG Paul
Jochen Schulz
> Jochen Schulz wrote:
>> Reinhold Plew:
>
>>> 'Service' zur Verfügung zu stellen.
>>
>> Doch, das ist in den Größenordnungen von GMX & Co schon relevant, weil
>> die deutlich mehr Hardware für ihre 10 Millionen Kunden bräuchten, die
>> alle zwanzig Minuten (oder wie oft auch immer es zugelassen wird)
>> pollen.
>
> Das regelmäßige Pollen läuft i.A. über POP3, nicht über HTTP. Und bei
> POP3 ist auch in den FreeMail-Accounts SSL verfügbar.
Verfügbar, aber eben nicht zwingend. Und nur dafür wollte ich den Grund
nennen, weil Reinhold annahm, das würde den Anbieter nichts kosten.
J.
--
Fashion is more important to me than war, famine, disease or art.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Simon Bienlein
> Ist jetzt schon ein paar Jahre her, aber als ich mir mal angeguckt hab,
> was in meiner FH alles über das unverschlüsselte WLAN geht... sagen wir,
> es war erschreckend, wie wenig Problembewußtsein unter meinen
> Kommolitonen (Fach Wirtschaftsinformatik) vorhanden war. Und ihre
> Software hat ihnen nicht gerade geholfen.
das kann ich mir gut vorstellen. Ich werde mich bei Gelegenheit auch
einmal mit dem angucken des Traffics im LAN beschäftigen.
Jochen Schulz
> Jochen Schulz:
>
>> Ist jetzt schon ein paar Jahre her, aber als ich mir mal angeguckt hab,
>> was in meiner FH alles über das unverschlüsselte WLAN geht... sagen wir,
>> es war erschreckend, wie wenig Problembewußtsein unter meinen
>> Kommolitonen (Fach Wirtschaftsinformatik) vorhanden war. Und ihre
>> Software hat ihnen nicht gerade geholfen.
>
> das kann ich mir gut vorstellen. Ich werde mich bei Gelegenheit auch
> einmal mit dem angucken des Traffics im LAN beschäftigen.
Mach Dich nicht strafbar dabei. Bei mir ist es wahrscheinlich schon
verjährt. ;-)
J.
--
I think the environment will be okay.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Manfred Schmitt
>
> Am 20.11.2008 17:23, Manfred Schmitt schrieb:
> > Simon Bienlein schrieb:
> >>
> >> via plaintext einloggen. doch wie hätte ich mich sonst anmelden müssen?
> >> Habe im RFC 3501 gelesen, dass es neben dem Befehl LOGIN noch das
> >> Kommando AUTHENTICATE gibt. Evtl. schaffe ich es auf diesem Weg noch,
> >> mich ohne plaintext zunächst per telnet einzuloggen.
> >>
> > Ich glaub Du suchst imtest aus cyrus-clients-2.2.
>
> vielen Dank für deine Antwort. Dieses Paket benötige ich IMHO nur, wenn
> ich SSL verwende, oder?
Nun ja, imtest funktioniert soweit ich es sehe auch ohne ssl/tls und
imtest spricht imap und kennt einiges an Optionen wie z.B. eben auch
AUTHENTICATE oder LOGIN.
Und damit ist das testen halt generell weniger anstrengend als mit telnet,
ich vertipp mich einfach zu oft ;-)
Ich kannte cyrus-clients-2.2 uebrigens vor Deiner mail (auch) nicht und
hab rein interessehalber mal geschaut was es zum testen von "mailserver"-
Logins (besonders wenn ssl ins Spiel kommt) denn so neben swaks, das ja
nur smtp kann, noch so gibt.
Und wech,
Manne
Martin Reising
> hab rein interessehalber mal geschaut was es zum testen von "mailserver"-
> Logins (besonders wenn ssl ins Spiel kommt) denn so neben swaks, das ja
> nur smtp kann, noch so gibt.
Wie kommst du auf dieses schmale Brett?
Die Paketbschreibung von swaks ist da anderer Ansicht:
swaks (Swiss Army Knife SMTP) is a command-line tool written in Perl
for testing SMTP setups; it supports STARTTLS and SMTP AUTH (PLAIN,
LOGIN, CRAM-MD5, SPA, and DIGEST-MD5). swaks allows to stop the SMTP
dialog at any stage, e.g to check RCPT TO: without actually sending a
mail.
Manfred Schmitt
Also ich lese da immer noch nur was von smtp und z.B. nichts von imap?
OK, die Anfuehrungstriche um mailserver gehoeren da nicht hin, das war
Quatsch.
Martin Reising
> > On Wed, Nov 26, 2008 at 07:08:29PM +0100, Manfred Schmitt wrote:
> > > hab rein interessehalber mal geschaut was es zum testen von "mailserver"-
> > > Logins (besonders wenn ssl ins Spiel kommt) denn so neben swaks, das ja
> > > nur smtp kann, noch so gibt.
> >
> Quatsch.
swaks "kann" nicht nur smtp, sondern selbiges auch mit/über TLS,
womit "(besonders wenn ssl ins Spiel kommt)" nicht nur
mißverständlich, sondern schlicht weg flacsh ist.
Manfred Schmitt
Das "(besonders wenn ssl ins Spiel kommt)" bezog sich nicht explizit auf
swaks sondern generell auf "was es zum testen von "mailserver"-Logins"
... "gibt".
Denn spaetestens wenn ssl ins Spiel kommt wird es mit telnet anstrengend.
Sind nun alle Klarheiten beseitigt? ;-)