tester Postfix/TLS
Le test du module est un peu difficile, car la transmission est chiffrée, de
sorte que vous ne puissiez pas "imiter" la
conversation juste par un telnet sur le port smtp. Vous ne pouvez pas également
capturer les paquets (vous pouvez,
mais si tout fonctionne comme annoncé, cela ne vous aidera pas :-).
Outils de mise au point inclus:
Comme tous les messages générés par postfix sont envoyés
au système de journalisation, la mise au point doit être faite
en utilisant vos fichier de journalisation. Postfix/TLS supporte les niveaux
de journalisation de 0 (très calme) à 4 (vidange
mémoire de la conversation complète, non recommandé). Dans un premier temps
placez smpt[d]_tls_loglevel=2 et
observez le fichier journal. Typiquement vous aurez des problèmes avec l'accès
aux clés ou aux certificats, ainsi vous
trouverez des messages d'erreur ici. Vous pouvez toujours essayer d'envoyer
un email à postfix_tls-bounce@serv01.aet.tu-cottbus.de
avec le TLS activé de votre côté et regardez ce qui se produit
:-).
Tout en testant l'interopérabilité avec ZMailer nous avons appris qu'un certificat
incorrect (qui doit être le serveur pour le serveur :-) peut
mener à des erreurs de connexions sans messages clairs. cela peut nous
aider d'utiliser Netscape 4.5x en tant que client et d'étudier
soigneusement les informations ainsi que les boites de dialogue.
Je n'ai pas encore trouvé comment identifier le problème de postfix
à afficher un message approprié dans le fichier de journalisation.
Si tout va bien ce sera possible sans modifier les bibliothèques d'OpenSSL.
Plateformes:
Plateformes de développement:
OS: HP-UX 10.20
OS: Linux 2.x (SuSE Linux)
Succés enregistrés:
OS: Solaris 2.5 - Walcir Fontanini
Clients de test:
Software: Netscape 4.5x, Netscape 4.6x, Netscape 4.7x
OS: HP-UX 10.20, Linux 2.x, Win95
Intéropérabilité:
Sans compter le support par les solutions génériques d'emballage, il existe
des extensions particulièrement travaillés pour
d'autres MTA:
Qmail il y a un patch en sources libres disponible, étendant le MTA de Qmail
pour supporter la RFC2487,
écrit par Frederik Vermeulen . L'envoi et la réception fonctionne des deux côtés.
Test: envoyez le courrier à ping@linux.student.kuleuven.ac.be (renverra l'email
complet comprenant des en-têtes).
Zmailer l'autheur/développeur de ZMailer, Matti Aarnio, a incorporé le
support serveur et client de TLS .
Zmailer - > Postfix très bien,
Postfix - > Zmailer ne fonctionne pas, puisqu'Esmtp n'est pas identifié (problème
signalé).
Test: envoyez un courrier à autoanswer@mea.tmt.tele.fi (renverra des en-têtes).
Sendmail la verson commerciale supporte le client et le serveur TLS,
les deux côtés fonctionnent avec Postfix/TLS.
En date de sendmail-8.11, TLS est également inclus avec la version opensource
.
Test: envoyez le courrier à bounce@esmtp.org (reverra le message d'erreur comprenant
de vieux en-têtes).
Postfix: peut s'envoyer des messages à lui-même :-)
Test: envoyez le courrier à postfix_tls-bounce@serv01.aet.tu-cottbus.de (reviendra,
en incluant de vieux en-têtes).
D'autres retour sont les bienvenus
Problèmes connus:
Ce logiciel en est qu'à ses débuts, soyez donc patients. À ce
jour j'ai ces points:
Côté de serveur: Sous Win95/NT j'ai quelques problèmes avec les certificats
de client. En ouvrant la première connexion
(Netscape demande le mot de passe pour accéder à la base de données de certificat),
la connexion s'arrête. Ceci semble
être provoqué par Netscape: une vidange mémoire de la transmission montre que
Netscape ne reprend pas la poignée de main
(TLS handshake) de TLS.
Remarque: je n'ai pas pu reproduire cette anomalie récemment après évolution
d'OpenSSL 0.9.4. J'espère qu'elle a disparue,
mais peut-être est elle juste une conséquence du jeu autour avec les options
de la sécurité de Netscape. Plus de test exigé...
Solution: détruisez cette connexion, la prochaine fonctionnera immédiatement
ou utilisez SSLv2 seulement (deuxième solution
non recommandée).
Doit être résolu avec OpenSSL 0.9.5
Coté serveur: Outlook Express tout comme Internet explorer 5 fonctionneront
avec Postfix/TLS mais aucun certificat
client ne seront présentés. Ainsi vous pouvez chiffrer votre transfert
de courrier mais vous ne pouvez pas vous authentifier
(et relayer) avec des certificats clients. Cela fonctionne seulement sur le
port 25 (smtp); sur d'autres ports vous devez
utiliser le smtpd_tls_wrappermode à la place.
Coté serveur: Outlook Express tout comme Internet explorer 4 semble
ne pas supporter la RFC2487. Utilisez
smtpd_tls_wrappermode=yes sur un autre port.
Coté serveur: Outlook Express (Mac) semble ne pas supporter la RFC2487.
Utilisez smtpd_tls_wrappermode=yes
sur un autre port.
Coté client: MS Exchange même en version récente offre STARTTLS
même si ce dernier n'est pas configuré (la liste
de diffusion[IETF-APPS-TLS]). Je ne pourrais pas tester ceci sans accès à un
tel serveur, je ne peux donc pas prévoir
ce qui va se produire.
Coté client: Les connexions de TLS à un serveur de CommunigatePro échouent
avec une erreur de poignée de main
avec des versions plus anciennes de CommunigatePro. La raison est une violation
de protocole de CommunigatePro
en ce qui concerne la numérotation de version de protocole SSL. (cf RFC 2246
section 7.4.7.1)
Ce problème a été fixé dans CommunigatePro 3.3b?? (je ne connais pas la numérotation
exacte) autour du 9 juin 2000. .