Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comm.software.mailreader > #231 > unrolled thread
| Started by | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| First post | 2017-04-11 13:18 -0400 |
| Last post | 2017-04-29 11:41 -0400 |
| Articles | 10 — 4 participants |
Back to article view | Back to de.comm.software.mailreader
[mutt] Authentification (Plain) Andreas Kohlbach <ank@spamfence.net> - 2017-04-11 13:18 -0400
Re: [mutt] Authentification (Plain) Helmut Springer <delta+usenet@lug-s.org> - 2017-04-11 19:33 +0000
Re: [mutt] Authentification (Plain) Andreas Kohlbach <ank@spamfence.net> - 2017-04-12 17:17 -0400
Re: [mutt] Authentification (Plain) dseppi@a1.net (David Seppi) - 2017-04-13 10:23 +0000
Re: [mutt] Authentification (Plain) Thomas Hochstein <thh@inter.net> - 2017-04-14 11:36 +0200
Re: [mutt] Authentification (Plain) dseppi@a1.net (David Seppi) - 2017-04-14 13:43 +0000
Re: [mutt] Authentification (Plain) Andreas Kohlbach <ank@spamfence.net> - 2017-04-14 15:58 -0400
Re: [mutt] Authentification (Plain) Helmut Springer <delta+usenet@lug-s.org> - 2017-04-14 20:54 +0000
Re: [mutt] Authentification (Plain) Thomas Hochstein <thh@inter.net> - 2017-04-29 14:42 +0200
Re: [mutt] Authentification (Plain) Andreas Kohlbach <ank@spamfence.net> - 2017-04-29 11:41 -0400
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2017-04-11 13:18 -0400 |
| Subject | [mutt] Authentification (Plain) |
| Message-ID | <871ssyq2vx.fsf@usenet.ankman.de> |
Wenn mutt sich mit imaps://imap.gmail.com/ hier verbindet, funktioniert das zwar. Wenn ich beim Einloggen aber genau hinschaue, sehe ich kurz | Authentification (Plain) Das ist nicht erwünscht. Wie sage ich in der ~/.muttrc , er solle sich nur verschlüsselt verbinden. Andererseits müsste er das nicht eh, weil Google sicher keine unverschlüsselte Autorisation erlaubt, und diese Meldung wäre dann selbst ein Fehler? Man findet auch wenig darüber im Web. -- Andreas You know you are a redneck if you've ever been involved in a custody fight over a huntin' dog.
[toc] | [next] | [standalone]
| From | Helmut Springer <delta+usenet@lug-s.org> |
|---|---|
| Date | 2017-04-11 19:33 +0000 |
| Message-ID | <0Tddlv5mI2a7Nv8@delta.citecs.de> |
| In reply to | #231 |
Andreas Kohlbach <ank@spamfence.net> wrote:
> Wenn mutt sich mit imaps://imap.gmail.com/ hier verbindet, funktioniert
Das ist imaps, also eine per SSL/TLS gesicherte Verbindung.
> das zwar. Wenn ich beim Einloggen aber genau hinschaue, sehe ich kurz
>
> | Authentification (Plain)
Das ist die Authentication gegenueber dem IMAP Server (SASL Plain),
das hat mit der Verbindung nichts zu tun sondern geschieht ueber die
etablierte Verbindung.
> Das ist nicht erwünscht.
Bist Du sicher, dass Du das nicht willst?
> Wie sage ich in der ~/.muttrc , er solle sich nur verschlüsselt
> verbinden.
Du vermischt "Verbindung" und "IMAP Authentication", die hier
unabhaengig voneinander sind.
> Andererseits müsste er das nicht eh, weil Google sicher keine
> unverschlüsselte Autorisation erlaubt, und diese Meldung wäre dann
> selbst ein Fehler? Man findet auch wenig darüber im Web.
Man konnte die manpage lesen, muttrc.5 beinhaltet
imap_authenticators
Type: string
Default: ??????
This is a colon-delimited list of authentication
methods mutt may attempt to use to log in to an IMAP
server, in the order mutt should try them.
Authentication methods are either ???login??? or the right
side of an IMAP ???AUTH=xxx??? capability string, e.g.
???digest-md5???, ???gssapi??? or ???cram-md5???. This option is
case-insen??? sitive. If it's unset (the default) mutt
will try all available methods, in order from
most-secure to least-secure.
Example:
set imap_authenticators=???gssapi:cram-md5:login???
Note: Mutt will only fall back to other
authentication methods if the previous methods are
unavailable. If a method is avail??? able but
authentication fails, mutt will not connect to the
IMAP server.
--
Best Regards
helmut springer panta rhei
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2017-04-12 17:17 -0400 |
| Message-ID | <87efwx2um8.fsf@usenet.ankman.de> |
| In reply to | #232 |
On 11 Apr 2017 19:33:18 GMT, Helmut Springer wrote: > > Andreas Kohlbach <ank@spamfence.net> wrote: >> Wenn mutt sich mit imaps://imap.gmail.com/ hier verbindet, funktioniert > > Das ist imaps, also eine per SSL/TLS gesicherte Verbindung. > >> das zwar. Wenn ich beim Einloggen aber genau hinschaue, sehe ich kurz >> >> | Authentification (Plain) > > Das ist die Authentication gegenueber dem IMAP Server (SASL Plain), > das hat mit der Verbindung nichts zu tun sondern geschieht ueber die > etablierte Verbindung. Also Klardaten über eine sonst verschlüsselte Verbindung "getunnelt"? Würde okay sein. >> Das ist nicht erwünscht. > > Bist Du sicher, dass Du das nicht willst? Eine nicht verschlüsselte Verhandlungsphase will ich nicht. >> Wie sage ich in der ~/.muttrc , er solle sich nur verschlüsselt >> verbinden. > > Du vermischt "Verbindung" und "IMAP Authentication", die hier > unabhaengig voneinander sind. > > >> Andererseits müsste er das nicht eh, weil Google sicher keine >> unverschlüsselte Autorisation erlaubt, und diese Meldung wäre dann >> selbst ein Fehler? Man findet auch wenig darüber im Web. > > Man konnte die manpage lesen, muttrc.5 beinhaltet > > imap_authenticators > [...] Brauche ich dann also nicht, da die Daten wegen meiner Fehlinterpretation sicher sind. Danke. -- Andreas You know you are a redneck if you've ever hitchhiked naked,
[toc] | [prev] | [next] | [standalone]
| From | dseppi@a1.net (David Seppi) |
|---|---|
| Date | 2017-04-13 10:23 +0000 |
| Message-ID | <2017-04-13$10.21.02@tin.seppi.name> |
| In reply to | #233 |
Andreas Kohlbach schrieb: > Also Klardaten über eine sonst verschlüsselte Verbindung "getunnelt"? > Würde okay sein. Exakt. Hat den Vorteil, daß das Paßwort am Server nicht gespeichert werden muß. Ein Hash reicht. (Das geht zwar bei ein paar verschlüsselten Übermittlungen auch, aber dann muß der Hash auf dieses Verfahren abgestimmt sein. Das erspart man sich hier, da eh der Transport verschlüsselt ist.) -- David Seppi 1220 Wien
[toc] | [prev] | [next] | [standalone]
| From | Thomas Hochstein <thh@inter.net> |
|---|---|
| Date | 2017-04-14 11:36 +0200 |
| Message-ID | <dcsm.1704141136.243@meneldor.ancalagon.de> |
| In reply to | #233 |
Andreas Kohlbach schrieb: > Also Klardaten über eine sonst verschlüsselte Verbindung "getunnelt"? Ja. Eine "verschlüsselte" Anmeldung, bei der das Passwort nicht im Klartext ausgetauscht wird, sondern nur ein Hash, wäre (a) unnötig, weil die Verbindung ja bereits gesichert ist, und hätte (b) den Nachteil, dass das Passwort dann auf der Serverseite zwingend unverschlüsselt gespeichert sein muss.
[toc] | [prev] | [next] | [standalone]
| From | dseppi@a1.net (David Seppi) |
|---|---|
| Date | 2017-04-14 13:43 +0000 |
| Message-ID | <2017-04-14$13.37.36@tin.seppi.name> |
| In reply to | #235 |
Thomas Hochstein schrieb: > Eine "verschlüsselte" Anmeldung, bei der das Passwort nicht im > Klartext ausgetauscht wird, sondern nur ein Hash, wäre (a) unnötig, > weil die Verbindung ja bereits gesichert ist, und hätte (b) den > Nachteil, dass das Passwort dann auf der Serverseite zwingend > unverschlüsselt gespeichert sein muss. Nicht zwingend. Es gibt Authentifizierungsmethoden, bei denen zwar das Paßwort verschlüsselt übertragen wird, der Server abee trotzdem nur einen (auf das Authentifizierungsverfahren angepaßten) Hash speichern muß. Das ist dann allerdings unflexibel, da nur die zum Hashverfahren passende Methode angeboten werden kann, die u.U. von einigen Clients nicht unterstützt wird. -- David Seppi 1220 Wien
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2017-04-14 15:58 -0400 |
| Message-ID | <87zifiwykn.fsf@usenet.ankman.de> |
| In reply to | #235 |
On Fri, 14 Apr 2017 11:36:19 +0200, Thomas Hochstein wrote: > > Andreas Kohlbach schrieb: > >> Also Klardaten über eine sonst verschlüsselte Verbindung "getunnelt"? > > Ja. > > Eine "verschlüsselte" Anmeldung, bei der das Passwort nicht im > Klartext ausgetauscht wird, sondern nur ein Hash, wäre (a) unnötig, > weil die Verbindung ja bereits gesichert ist, und hätte (b) den > Nachteil, dass das Passwort dann auf der Serverseite zwingend > unverschlüsselt gespeichert sein muss. :-) Wenn auch technisch korrekt, sollte mutt dann aber diese Meldung unterdrücken, um Verwirrung zu vermeiden. Die Meldung bringt keinen wirklichen Nutzwert. -- Andreas You know you are a redneck if your mother has been involved in a fistfight at a high school sport event.
[toc] | [prev] | [next] | [standalone]
| From | Helmut Springer <delta+usenet@lug-s.org> |
|---|---|
| Date | 2017-04-14 20:54 +0000 |
| Message-ID | <0Tddu1cjIs8tNv8@delta.citecs.de> |
| In reply to | #237 |
Andreas Kohlbach <ank@spamfence.net> wrote: > Wenn auch technisch korrekt, sollte mutt dann aber diese Meldung > unterdrücken, um Verwirrung zu vermeiden. Ich sehe da keinen Grund fuer Verwirrung. Letztlich kann alles verwirren, wenn man sich nicht auskennt. Das daraus folgende Benutzerinerface ist idR maximal entmuendigend und entspricht nicht unbedingt der mutt-Philosohpie. > Die Meldung bringt keinen wirklichen Nutzwert. Sie gibt die verwendete Authentication bekannt, und dass das password als solches an den server ging. Es gibt Leute, die das interessiert, koennte uebrigens von libsasl kommen *shrug* -- Best Regards helmut springer panta rhei
[toc] | [prev] | [next] | [standalone]
| From | Thomas Hochstein <thh@inter.net> |
|---|---|
| Date | 2017-04-29 14:42 +0200 |
| Message-ID | <dcsm.1704291442.253@meneldor.ancalagon.de> |
| In reply to | #237 |
Andreas Kohlbach schrieb: > Wenn auch technisch korrekt, sollte mutt dann aber diese Meldung > unterdrücken, um Verwirrung zu vermeiden. Darüber kann man streiten. Ich neige zu der Auffassung, dass es insgesamt vorzugswürdig ist, die verwendete Methode mitzuteilen, eine möglicherweise entstehende Verwirrung hinzunehmen und bestenfalls noch einen Wissenszuwachs beim Benutzer zu erreichen. ;) > Die Meldung bringt keinen wirklichen Nutzwert. Sie gibt die verwendete Authentifizierungs-Methode an. Die heißt eben "plain" - was eine konkrete Methode bezeichnet und nicht "im Klartext und unverschlüsselt" bedeutet. Diese Angabe halte ich für durchaus wünschenswert. -thh
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2017-04-29 11:41 -0400 |
| Message-ID | <87ziezw7aq.fsf@usenet.ankman.de> |
| In reply to | #241 |
On Sat, 29 Apr 2017 14:42:53 +0200, Thomas Hochstein wrote: > > Andreas Kohlbach schrieb: > >> Wenn auch technisch korrekt, sollte mutt dann aber diese Meldung >> unterdrücken, um Verwirrung zu vermeiden. > > Darüber kann man streiten. Ich neige zu der Auffassung, dass es > insgesamt vorzugswürdig ist, die verwendete Methode mitzuteilen, eine > möglicherweise entstehende Verwirrung hinzunehmen und bestenfalls noch > einen Wissenszuwachs beim Benutzer zu erreichen. ;) Ich bevorzuge, dass nur Meldungen zu kritischen Ereignissen kommen per Default. Der User aber auch in der Lage sein sollte, den Verbose-Level anpassen zu können, wünscht er mehr (oder weniger) Information. >> Die Meldung bringt keinen wirklichen Nutzwert. > > Sie gibt die verwendete Authentifizierungs-Methode an. Die heißt eben > "plain" - was eine konkrete Methode bezeichnet und nicht "im Klartext > und unverschlüsselt" bedeutet. Diese Angabe halte ich für durchaus > wünschenswert. Das wird normale Vorgehensweise, nicht nur bei mutt, sein. Daher IMO überflüssig, es zu erwähnen. Wenn aber mal eine "nicht normale" Methode genommen würde, hielt ich es schon wünschenswert, sie zu erwähnen. Andererseits machen auch andere Programme das. Ich hatte mal bei Firefox besonders drauf geachtet, was der unten in der Statusleiste anzeigt. Der erzählt auch zu viel. Wie dass er gerade eine Verbindung herstellen will (Ach was?). Gut, dass man hier diese Leiste ausblenden kann. -- Andreas You know you are a redneck if you've never paid for a haircut.
[toc] | [prev] | [standalone]
Back to top | Article view | de.comm.software.mailreader
csiph-web