Mot-clé - courriel

Fil des billets

dimanche 26 janvier 2014

SMTP Postfix en accord avec les RFC mais n'acceptant pas les utilisateurs s'authentifiant en clair

Quand on met à disposition un serveur SMTP à des utilisateurs, on aimerait s'assurer qu'ils ne communiquent pas leur mot de passe clair. Une solution consiste à interdire tout accès au SMTP sans SSL/TLS :

smtpd_tls_security_level = encrypt

mais cette option n'est pas compatible avec les RFC car alors tous les SMTPs doivent se connecter au vôtre avec SSL/TLS.

Il existe donc une autre possibilité plus élégante :

smtpd_tls_security_level = may
smtpd_tls_auth_only = yes

'' smtpd_tls_security_level = may'' autorise l'accès au serveur sans encryption (même si l'encryption est utilisée prioritairement si possible) tandis que "smtpd_tls_auth_only = yes" n'autorise les actions d'authentification (donc d'échange de mot de passe) que lorsque la connexion passe par un canal crypté.

Voilà qui répond au problème tout en respectant les RFC !

vendredi 11 octobre 2013

Reverse IPv6 avec DNSMasq, chez Online.net

Comme raconté ici, le postmaster de Google a adopté une position très stricte de rejet de tout courriel provenant d'un serveur SMTP se connectant en IPv6 mais ne disposant pas de champ 'reverse' concordant.

On peut déplorer cette très grande rigidité et s'en étonner, surtout dans une période d'adoption progressive de l'IPv6. Pour ceux dont le fournisseur d'accès (plus précisément le fournisseur de votre bloc d'adresses IPv6) ne donne aucun moyen d'avoir un 'reverse', une solution temporaire est proposée ici : connexion en IPv4 à Google.

Dans le cas d'Online.net, la possibilité d'une délégation DNS est apparue récemment en production. Elle permet d'indiquer à quel serveur DNS se raccrocher pour effectuer la translation de nom inverse (i.e. d'adresse IP vers nom de domaine) pour les adresses du bloc.

Etape 1 : disposer d'un serveur DNS capable de répondre aux requêtes "reverse"

La grande référence du DNS est bind, mais on peut également monter ce petit service en moins de 10 lignes de configuration avec DNSMasq (dont je parlais déjà ici).

On installe dnsmasq par

aptitude install dnsmasq

et voici un exemple de configuration complète :

log-facility=/var/log/dnsmasq.log
log-queries
no-resolv
no-hosts
ptr-record=0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.h.g.f.e.d.c.b.a.1.0.0.2.ip6.arpa,monreverse1.domain.tld
ptr-record=1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.h.g.f.e.d.c.b.a.1.0.0.2.ip6.arpa,monreverse2.domain.tld

Les paramètres log-facility et log-queries indiquent que l'on souhaite garder une trace de toutes les requêtes DNS dans /var/log/dnsmasq.log

no-resolv et no-host ainsi que l'absence de paramètre server indiquent que l'on ne souhaite répondre positivement qu'aux requêtes correspondant à l'un des enregistrements mentionnés dans le fichier de configuration.

Et enfin, sont indiqués les 2 enregistrements PTR qui correspondent à 2 adresse IPv6 pour lesquelles on souhaite avoir un reverse IPv6.

La première adresse est 2001:abcd:efgh:100:: et la seconde est 2001:abcd:efgh:100::101. On voit que l'adresse est mentionnée dans l'enregistrement PTR en l'écrivant "à l'envers" et en séparant chaque caractère (y compris les 0 que la convention nous permet de ne pas faire apparaître dans les adresses IPv6) par un point.

Etape 2 :

On rend ce serveur DNS très simple (et capable de ne répondre qu'à ces 2 requêtes reverse IPv6) accessible à l'adresse dns.domain.tld. Si on est placé derrière un firewall, on n'oubliera pas d'ouvrir le port 53 en TCP et en UDP.

Etape 3 : paramétrer la délégation DNS chez le fournisseur du bloc IPv6

Cette étape diffère selon le fournisseur du bloc IPv6. Chez Online, il faut se rendre dans la console, onglet "Serveur" puis "Paramétrage du réseau". On choisit le bloc IPv6 de son choix et on clique sur l'option "Paramétrer la délégation DNS". On saisit alors l'adresse du serveur DNS capable de répondre aux éventuelles requêtes reverse IPv6.

Délégation DNS chez Online

Etape 4 : on peut à nouveau écrire aux destinataires de GMail

Si on expédie un message à un destinataire @gmail.com, quelques secondes plus tard, on voit apparaître dans les logs la requête DNS suivante :

Oct 6 14:04:59 dnsmasq[21288]: query[PTR] 
1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.h.g.f.e.d.c.b.a.1.0.0.2.ip6.arpa **from 74.125.18.211**

74.125.18.211 est une adresse (IPv4 !) de Google qui vient s'enquérir du reverse IPv6. Et le courriel est expédié sans encombre !

Bons paramétrages de reverse IPv6 à tous !

samedi 11 mai 2013

Un serveur courriel qui bloque quand mon ordinateur, ma tablette et mon téléphone se connectent...

Hébergeant mon propre serveur courriel, je butais depuis quelques temps sur un problème ennuyeux. De temps à autre, mon téléphone ou ma tablette Android refusaient la connexion au serveur courriel en avançant la raison d'un mot de passe incorrect. Longtemps, je crus à un bogue des clients Android jusqu'au moment où Thunderbird, par moment, se mit également à me refuser l'accès. Comment diable expliquer cette panne aléatoire et que quelques heures d'attente suffisaient généralement à résoudre ?

Je plongeais donc dans les logs du serveur Dovecot et fouillais. Voilà, je tenais le coupable : tous mes périphériques se connectaient depuis la même IP (partageant par exemple un même Wifi) et Dovecot refusait les pressants appels au nom de cette directive :

mail_max_userip_connections = 10

Un coup de nano (ndla un éditeur texte en ligne de commande pour ceux qui ne connaîtraient pas, l'équivalent de mon tournevis numérique) et je faisais disparaître (ou plutôt croître) la stricte limite ! Après un redémarrage de Dovecot, je n'avais plus aucun problème de connection au serveur IMAP ! Ouf, le standard faisait bien les choses et il n'y avait pas de bogue vicieux caché dans les divers clients ou le serveur !