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}xxxxxx). 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...).
Reply to: