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 ... ?
--
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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
mouss
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.
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 with a subject of "unsubscribe". Trouble? Contact
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.
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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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.
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 with a subject of "unsubscribe". Trouble? Contact
