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]
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:
[...]
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
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:
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
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]
