Re: Serveur de mails et mécanismes SASL
>> 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 il est représenté). vérification faite, dovecot supporte la
> notation {scheme}. ce qui veut dire que tu peux utiliser un format
> différent par utilisateur. si en plus tu utilises dovecot comme
> implementation sasl pour postfix, ça simplifie les choses. mais bon,
> pour un mécanisme à challenge, le mot de passe doit être stocké en
> clair
> (doit être "retrouvable" en tout cas). il n'y a donc que pour PLAIN et
> LOGIN qu'on peut stocker juste un hash.
Cela devient tordu si il faut travailler avec un format spécifique par
utilisateur, mais par contre cela devient aussi très puissant.
En tout cas pour l'instant je suis très content de dovecot/postfix.
---
Franck Joncourt
http://www.debian.org/ - http://smhteam.info/wiki/
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serveur de mails et mécanismes SASL
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 ne sais pas
>> si on peut le faire avec les implementations existantes. peut-etre avec
>> dovecot, à moins de passer par PAM avec un patch ou un truc du genre.
>
> 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 il est représenté). vérification faite, dovecot supporte la
notation {scheme}. ce qui veut dire que tu peux utiliser un format
différent par utilisateur. si en plus tu utilises dovecot comme
implementation sasl pour postfix, ça simplifie les choses. mais bon,
pour un mécanisme à challenge, le mot de passe doit être stocké en clair
(doit être "retrouvable" en tout cas). il n'y a donc que pour PLAIN et
LOGIN qu'on peut stocker juste un hash.
>
> [...]
>
>> cram-md5 est plus courant: il y a plus de clients qui le supportent.
>
> Ok, je prends note.
>
> ---
> Franck Joncourt
> http://www.debian.org/ - http://smhteam.info/wiki/
>
>
>
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serveur de mails et mécanismes SASL
>> 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 peut le faire avec les implementations existantes. peut-etre avec
> dovecot, à moins de passer par PAM avec un patch ou un truc du genre.
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.
[...]
> cram-md5 est plus courant: il y a plus de clients qui le supportent.
Ok, je prends note.
---
Franck Joncourt
http://www.debian.org/ - http://smhteam.info/wiki/
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serveur de mails et mécanismes SASL
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 mentionné LOGIN :p!
>
>>> * Doit-on proposer plus d'un _non_plaintext mécanism_ tel que
>>> DIGEST-MD5, CRAM-MD5 et utiliser des mots de passe en clair pour
>>> le stockage ?
>>>
>>> * Quels sont les mécanismes minimums à fournir en SMTP, SUBMISSION,
>>> IMAP ... ?
>> La réponse aux deux question dépend des logiciels de mail qui vont
>> accéder aux serveurs. grosso mod:
>>
>> question submission/smtp, digest-md5 est supporté par Sylpheed, The
>> Bat!, Mulberry, Novel Edition, Wanderlust... je ne sais pas si ça fait
>> suffisamment d'utilisateurs sur ton système pour justifier le boulot.
>> Regarde sur
>> http://www.melnikov.ca/mel/devel/SASL_ClientRef.html
>> pour le support sasl de différents mailers.
>
> Sympa !
> 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 peut le faire avec les implementations existantes. peut-etre avec
dovecot, à moins de passer par PAM avec un patch ou un truc du genre.
> C'est ce
> que
> j'aurais aimé, mais je pense que je vais me tourner vers DIGEST-MD5
> autrement c'est vrai que j'ai le TLS disponible.
>
cram-md5 est plus courant: il y a plus de clients qui le supportent.
>> D'autre part, si tu forces TLS, PLAIN et LOGIN sont suffisants et il est
>> inutile de se batter avec *-MD5.
>
> Cela ne me dérange pas, au contraire, je trouve cela intéressant d'aller
> creuser la configuration et de voire les différentes solutions qui
> existent,
> et de comprendre la mécanique.
>
Dison que ce n'est pas la peine de faire faire des calculs intuiles au
client et au serveur quand ils en ont déjà fait pour parler TLS.
>> si t'as des utilisateurs outlook, tu risques de devoir activer le port
>> 465 (smtps), qui est l'ancien service pour smtp sur ssl (obsolete depuis
>> belle lurette, mais bon).
>>
>> LOGIN est uniquement nécessaire pour les clients qui ne supportent pas
>> le "vrai" standard, comme outlook (encore lui). dans ce cas, ton serveur
>> smtp doit proposer la syntaxe obseolete (220-AUTH=LOGIN ... avec un '='
>> au lieu d'un espace). sur postfix, il faut activer
>> broken_sasl_auth_clients.
>
> Oui je connais mais c'est vrai que je n'ai pas pensé à mettre smtps en
> place.
> Cela m'embête plus car c'est un cas isolé, du moins il me semble.
> D'ailleurs Outlook lui-même, m'agace un peu car il faut configurer des
> options
> spécialement pour lui.
oui, mais il est très utilisé! (et en plus, il y a N versions, et comme
beaucoup utilisent des versions craquées ou du moins ne peuvent pas
upgrader, ça fait un gros bordel à gérer...).
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serveur de mails et mécanismes SASL
[...] >> 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-on proposer plus d'un _non_plaintext mécanism_ tel que >> DIGEST-MD5, CRAM-MD5 et utiliser des mots de passe en clair pour >> le stockage ? >> >> * Quels sont les mécanismes minimums à fournir en SMTP, SUBMISSION, >> IMAP ... ? > > La réponse aux deux question dépend des logiciels de mail qui vont > accéder aux serveurs. grosso mod: > > question submission/smtp, digest-md5 est supporté par Sylpheed, The > Bat!, Mulberry, Novel Edition, Wanderlust... je ne sais pas si ça fait > suffisamment d'utilisateurs sur ton système pour justifier le boulot. > Regarde sur > http://www.melnikov.ca/mel/devel/SASL_ClientRef.html > pour le support sasl de différents mailers. Sympa ! 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é. C'est ce que j'aurais aimé, mais je pense que je vais me tourner vers DIGEST-MD5 autrement c'est vrai que j'ai le TLS disponible. > D'autre part, si tu forces TLS, PLAIN et LOGIN sont suffisants et il est > inutile de se batter avec *-MD5. Cela ne me dérange pas, au contraire, je trouve cela intéressant d'aller creuser la configuration et de voire les différentes solutions qui existent, et de comprendre la mécanique. > si t'as des utilisateurs outlook, tu risques de devoir activer le port > 465 (smtps), qui est l'ancien service pour smtp sur ssl (obsolete depuis > belle lurette, mais bon). > > LOGIN est uniquement nécessaire pour les clients qui ne supportent pas > le "vrai" standard, comme outlook (encore lui). dans ce cas, ton serveur > smtp doit proposer la syntaxe obseolete (220-AUTH=LOGIN ... avec un '=' > au lieu d'un espace). sur postfix, il faut activer > broken_sasl_auth_clients. Oui je connais mais c'est vrai que je n'ai pas pensé à mettre smtps en place. Cela m'embête plus car c'est un cas isolé, du moins il me semble. D'ailleurs Outlook lui-même, m'agace un peu car il faut configurer des options spécialement pour lui. --- Franck Joncourt http://www.debian.org/ - http://smhteam.info/wiki/ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serveur de mails et mécanismes SASL
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 / CRAM-MD5 > > J'ai l'intention d'inhiber PLAIN en IMAP et POP3 > > * SMTP - LOGIN / CRAM-MD5 avec TLS disponible 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. > * SUBMISSION - PLAIN / LOGIN / CRAM-MD5 > avec TLS obligatoire > > Il y a quelques temps, il me semble que j'avais trouvé une RFC qui > mentionnait l'utilisation des _plaintext_ ou _non-plaintext mechanisms_ > pour la mise en place d'un serveur de mail ; mais je n'arrive plus à > mettre la main dessus. > > L'utilisation de CRAM-MD5 comme mécanisme impose que le mot > de passe soit stocké en PLAIN ou CRAM-MD5. Or je voudrais ajouter > le mécanisme DIGEST-MD5, mais cela implique un mot de passe stocké > en PLAIN ou DIGEST-MD5. Donc incompatibilité entre DIGEST-MD5 > et CRAM-MD5 à moins d'un mot de passe en PLAIN. > > Par conséquent, je me pose quelques questions : > > * Doit-on proposer plus d'un _non_plaintext mécanism_ tel que > DIGEST-MD5, CRAM-MD5 et utiliser des mots de passe en clair pour > le stockage ? > > * Quels sont les mécanismes minimums à fournir en SMTP, SUBMISSION, > IMAP ... ? La réponse aux deux question dépend des logiciels de mail qui vont accéder aux serveurs. grosso mod: question submission/smtp, digest-md5 est supporté par Sylpheed, The Bat!, Mulberry, Novel Edition, Wanderlust... je ne sais pas si ça fait suffisamment d'utilisateurs sur ton système pour justifier le boulot. Regarde sur http://www.melnikov.ca/mel/devel/SASL_ClientRef.html pour le support sasl de différents mailers. D'autre part, si tu forces TLS, PLAIN et LOGIN sont suffisants et il est inutile de se batter avec *-MD5. si t'as des utilisateurs outlook, tu risques de devoir activer le port 465 (smtps), qui est l'ancien service pour smtp sur ssl (obsolete depuis belle lurette, mais bon). LOGIN est uniquement nécessaire pour les clients qui ne supportent pas le "vrai" standard, comme outlook (encore lui). dans ce cas, ton serveur smtp doit proposer la syntaxe obseolete (220-AUTH=LOGIN ... avec un '=' au lieu d'un espace). sur postfix, il faut activer broken_sasl_auth_clients. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Serveur de mails et mécanismes SASL
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 / CRAM-MD5 J'ai l'intention d'inhiber PLAIN en IMAP et POP3 * SMTP - LOGIN / CRAM-MD5 avec TLS disponible * SUBMISSION - PLAIN / LOGIN / CRAM-MD5 avec TLS obligatoire Il y a quelques temps, il me semble que j'avais trouvé une RFC qui mentionnait l'utilisation des _plaintext_ ou _non-plaintext mechanisms_ pour la mise en place d'un serveur de mail ; mais je n'arrive plus à mettre la main dessus. L'utilisation de CRAM-MD5 comme mécanisme impose que le mot de passe soit stocké en PLAIN ou CRAM-MD5. Or je voudrais ajouter le mécanisme DIGEST-MD5, mais cela implique un mot de passe stocké en PLAIN ou DIGEST-MD5. Donc incompatibilité entre DIGEST-MD5 et CRAM-MD5 à moins d'un mot de passe en PLAIN. Par conséquent, je me pose quelques questions : * Doit-on proposer plus d'un _non_plaintext mécanism_ tel que DIGEST-MD5, CRAM-MD5 et utiliser des mots de passe en clair pour le stockage ? * Quels sont les mécanismes minimums à fournir en SMTP, SUBMISSION, IMAP ... ? Merci. --- Franck Joncourt http://www.debian.org/ - http://smhteam.info/wiki/ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
