>> Je ne pense pas dire de bêtises en disant que si on stocke les mots de
>> passe en clair, il devient simple de mettre en place différents
>> _non-plaintext mecanisms_ (sous dovecot). Mais bon c'est en clair.
>
> oui. au fait, je voulais parler des "formats" (schemes) de mot de passe
> (comment
Franck JONCOURT wrote:
>>> L'optique que j'ai c'est de fournir un nombre de mécanismes suffisants
>>> pour satisfaire tout le monde quelque soit ce qui est utilisé.
>> Dans ce cas, il faudrait pouvoir stoquer le méchanisme avec le mot de
>> passe (un peu genre {CRAM-MD5}xx). Malheureusement, je
>> L'optique que j'ai c'est de fournir un nombre de mécanismes suffisants
>> pour satisfaire tout le monde quelque soit ce qui est utilisé.
>
> Dans ce cas, il faudrait pouvoir stoquer le méchanisme avec le mot de
> passe (un peu genre {CRAM-MD5}xx). Malheureusement, je ne sais pas
> si on pe
Franck JONCOURT wrote:
> [...]
>>> J'ai l'intention d'inhiber PLAIN en IMAP et POP3
>> et pourquoi LOGIN et pas PLAIN? c'est pas bien d'être plus gentils avec
>> les outlooks qu'avec les logiciels qui implémentent des standards non
>> obsoletes.
>
> Je dirais que c'est parce que j'ai oublié de men
[...]
>> J'ai l'intention d'inhiber PLAIN en IMAP et POP3
>
> et pourquoi LOGIN et pas PLAIN? c'est pas bien d'être plus gentils avec
> les outlooks qu'avec les logiciels qui implémentent des standards non
> obsoletes.
Je dirais que c'est parce que j'ai oublié de mentionné LOGIN :p!
>> * Doit-o
Franck JONCOURT wrote:
> Bonsoir,
>
> Je configure actuellement un serveur de mails, et je m'attarde sur
> les mécanismes SASL.
>
> Ma configuration :
>
> * IMAP - non activé pour le moment
> * IMAPS - PLAIN / LOGIN / CRAM-MD5
> * POP3 - non activé pour le moment
> * POP3S - PLAIN / LOGIN / CRA
6 matches
Mail list logo