HOAB

History of a bug

Configuration OpenDKIM en multi-domaines

Rédigé par gorki Aucun commentaire

Le problème :

En complément à cet article http://hoab.fr/postfix-et-10-10-aux-tests-antispam

Solution :

C'est tout simple, c'est pour tracer.

Par rapport aux tutoriels référencés dans l'article précédent, la configuration /etc/opendkim.conf :

#Domain & Selector & KeyFile ignore avec Keytable

#Domain			origames.fr
#Selector		mail
#KeyFile		/etc/dkim/mail.private

KeyTable		/etc/dkim/KeyTable
InternalHosts		/etc/dkim/TrustedHosts
SigningTable		/etc/dkim/SigningTable

On demande à opendkim d'aller chercher les clés dans un fichier plutôt que d'avoir une clé unique.

  1. ajout de la ligne du domaine dans : /etc/dkim/SigningTable
<domaine.com> mail._domainkey.<domaine.com>
  1. ajout de la ligne du domaine dans : /etc/dkim/TrustedHosts
<domaine.com>
  1. ajout de la ligne du domaine dans : /etc/dkim/KeyTable
mail._domainkey.<domaine.com> <domine.com>:mail:/etc/dkim/keys/<domaine.com>/mail.private
  1. générer la clé DKIM
cd /etc/dkim/keys/<domaine.com>/
opendkim-genkey -t -s mail -d <domaine.com>

Et voilà, ça roule.

 

DNS et propagation lente

Rédigé par gorki Aucun commentaire

Le problème :

Avec un serveur dédié chez OVH, il arrive que l'on veuille gérer son DNS directement.

Donc le DNS primaire est votre serveur, OVH propose des DNS secondaires qui se synchronise avec vous. En général ces DNS secondaires sont plus utilisés par le reste du WEB que le votre.

Le serveur secondaire de chez OVH ne propagait pas mes modifications

Solution :

Bête comme choux, mais encore faut-il ne pas l'oublier, les enregistrements DNS ont un timestamp.

Il faut l'incrémenter à chaque fois, c'est sur ce critère que le DNS secondaire se remet à jour.

(On aurait aussi pu utiliser des outils tout fait, qui, eux, n'oublie pas ça !)

Sinon, éditer : /etc/bind/pri/mondomaine.fr et incrémenter la date (2015010107)

mondomaine.fr.	IN	SOA	mondomaine.fr. postmaster.mondomaine.fr. (
			2015010107
			21600
			3600
			604800
			86400 )
                IN      NS      ns1234.ovh.net.
                IN      NS      sdns2.ovh.net.
                IN      MX      10 mail.mondomaine.fr.
                IN      A       1.1.1.1

Ensuite

/etc/init.d/name reload
# ou tout autre commande suivant la version de votre système

 

 

Postfix et 10/10 aux tests antispam

Rédigé par gorki Aucun commentaire

Le problème :

Après avoir installé un serveur de mail. Gmail refusait les mails envoyés depuis ce serveur.

"Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1  https://support.google.com/mail/?p=ipv6_authentication_error for more 550 5.7.1 information"

Et là, il faut suivre les conseils vagues de Google, heureusement d'autres sites sont de meilleurs aides, exemple :  https://www.mail-tester.com/

Le contexte :

- un serveur de mail + un nom de domaine (MONDOMAINE)

- un deuxième serveur de mail qui envoie des mails sur ce même domaine

Solution :

Suivre les recommendations du site mail-tester :)

Cela m'a conduit à :

Déclarer des enregistrements DNS sur MONDOMAINE pour autoriser mon deuxième serveur à envoyer des mails :

SERVEUR2.MONDOMAINE IN    A   IP-SERVEUR-2
MONDOMAINE.	IN	TXT	"v=spf1 ip4:IP-SERVEUR-2 include:mx.ovh.com"
MONDOMAINE.	IN	SPF	"v=spf1 ip4:IP-SERVEUR-2 include:mx.ovh.com"

Vérifier que le postfix de mon 2eme serveur est identifié avec SERVEUR2.MONDOMAINE

  • maintenant les serveurs SMTP reçevant nos mails savent que le deuxième serveur est autorisé à les envoyé.
  • que le nom de domaine SERVEUR2.MONDOMAINE est cohérent avec qui est déclaré dans postfix
  • ne pas avoir configurer postfix en openrelay, mais ça il faut l'avoir fait exprès

Il faut aussi installer des signatures DKIM en sortant :

mail._domainkey.MONDOMAINE.	IN TXT    ( "v=DKIM1;t=s;k=rsa; p=clepublic" )
  • on aurait pu avoir glustork à la place comme selecteur ! C'est aussi le principe d'avoir X domaines et X sélecteur pour avoir des clés de chiffrement différentes
glustork._domainkey.MONDOMAINE.	IN TXT    ( "v=DKIM1;t=s;k=rsa; p=clepublic" )
  • des outis pour vérifier les DNS existent sur le Web (ici, , ...)
  • mais un petit DIG suffit aussi :
dig mail._domainkey.<domaine>.fr TXT @dnsserver.com

 

Postfix sous debian en multidomaines

Rédigé par gorki Aucun commentaire

Le problème :

Comme d'autres, installer un serveur de mail sous une Debian.

En multidomaines.

Avec plusieurs serveurs de mails.

Solution :

Il y a d'excellent tutos sur Internet qui m'ont ammené quasiment la solution sur un plateau :

Solution générale :

  1. postfix (SMTP + STARTTLS only)
  2. délégation d'authentification à dovecot via SASL
  3. dovecot pour IMAP + POP (en STARTTLS only aussi)
  4. base de données pour les domaines multiples  via postfixadmin

Quelques notes sur les difficultés que j'ai rencontré :

  • une architecture de postfix : http://loic.marrot.free.fr/travaux/rapportProjetMessagerie.html
  • Un peu de vocabulaire sur les protocoles :
    • SMTP : pour envoyer des mails à un serveur de mail (depuis un client mail ou entre les serveurs de mails)
    • POP : du client mail au serveur mail pour aller récupérer ses mails
    • IMAP : idem que POP, mais il y a un échange pour synchroniser l'état du client et du serveur. Ainsi on peut avoir la même vision de ses mails depuis plusieurs endroits
    • SASL : protocole pour déléguer l'authentificaiton à un tiers. Exemple ici, postfix se base sur Dovecot pour savoir si un utilisateur est connu ou non. Entre Postfix et Dovecot, on fait du SASL
    • STARTTLS : afin de sécuriser les échanges par défaut non chiffré des différents protocoles (POP, IMAP, SMTP), on peut démarrer une session sécurisé à partir d'une connexion non sécurisée à la base. On démarre le TLS (sucesseur de SSL) : STARTTLS.
    • IMAPS, POPS : variante de POP et IMAP directement en TLS, mais peu usité, au profit du STARTTLS
    • Pour chacun de ces protocoles, il y a des ports par défaut que l'on retrouve dans /etc/services
  • Il est possible d'ajouter des logs en ajoutant "-v" aux différents démons postfix (cf la documentation officielle)
  • Le hostname de la machine et le DNS doivent être cohérent ! (cf hostame & postfix)
  • Posftixadmin & Thunderbird portable sont bien pratique pour tester des clients mails
  • Multiple domaines :
    • mydestination ne doit pas contenir les hosts virtuels stockés en BDD Mysql (voir virtual_mailbox_domains)
  • Pour le lien avec Dovecot
    • J'ai ajouté une ligne dans /etc/postfix/master.cf, comme indiqué dans certains tutoriaux plus haut
    • Je n'ai pas activé l'option #  -o smtpd_sasl_type=dovecot sur submission dans master.cf mais ajouté ces options dans main.cf
# SASL SMTPS
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
  • Bien valider l'authentification
    • pour Dovecot, utiliser le paramètre "ssl=required"
    • le paramètre smtpd_tls_auth_only peut-être mis à "no" le temps des tests, le mettre à "yes" ensuite
    • pour tester l'authentification (extrait d'ici) :
perl -MMIME::Base64 -e 'print encode_base64("username\0username\0password");'
  • swaks est outil super ! mais il ne faut oublier de préciser le serveur smtp (sinon il s'adresse directement au MX du domaine ciblé et ne passe pas par votre serveur !)
echo "This is the message body" | swaks --to web-4pDEEq@mail-tester.com --from "www-data@test.fr" --server localhost 25

Ca a suffit pour envoyer / recevoir des mails en TLS sur des noms de domaines que je maitrisais.

Pour ne pas être considéré comme spammeur, ce fut une autre histoire !

Mode réseaux Virtualbox et CentOS

Rédigé par gorki Aucun commentaire

Le problème :

La connexion réseau depuis une image CentOS sous VirtualBox vers un réseau entreprise un peu tatillon.

Dans un réseau entreprise, j'ai eu la surprise de voir le lancement de l'image VirtualBox "tuer" les prises réseaux.

Eh oui ! J'avais configuré ma VB en mode "Accès par pont".

Solution :

On commence par un petit pense-bête pour moi :

Par la suite :

  • VM = l'image que vous avez lancé sur VirtualBox
  • Réseau entreprise = le réseau auquel vous vous connectez avec votre PC
  • Réseau VB = réseau VirtualBox. Quand VB s'installe, il peut déployer une carte réseau virtuelle ce qui permet d'avoir un réseau propre à votre machine. Cette carte fait aussi serveur DHCP !

Les modes réseaux (Liste des modes réseaux VirtualBox, sur CCM):

- /!\ IMPORTANT /!\ : Accès par pont : adresse IP entreprise

  • la VM demande une autre adresse IP au réseau entreprise. (c'était mon problème : 2 adresses réseaux sur 1 même prise réseau => ZAG !)
  • Cela créé une deuxième machine indépendant de votre PC.

- /!\ IMPORTANT /!\ : NAT : adresse réseau local (10.0.x).

  • Adresse locale (inacessible depuis votre PC ou le réseau entreprise)
  • La redirection de port est intégré dans VirtualBox (sur la carte) c'est pratique
  • Donc en réalité un peu accessible via certains ports....

- Réseau NAT : jamais utilisé

  • a priori pour ne pas utiliser les adresses locales par défaut (10.0.x).
  • Permet de choisir un réseau via l'interface globale Virtualbox (partie réseau NAT)
  • Redirection de port à faire via l'interface globale Virtualbox plutôt que sur la configuration de la carte réseau (dans Virtualbox aussi)

- Réseau interne :

  • pas de réseau
  • seulement entre les VM. (à vérifier, jamais fait)
  • Les VM parlent aux VM, ici l'ombre (une sombre histoire à Achille Talon, si quelqu'un me retrouve la bulle... :))

- Réseau privé hôte : adresse IP donnée par la carte virtuelle VB

  • demande une adresse IP à la carte VB : on a créé un réseau interne entre le PC et la VM
  • Le PC et la VM se connaisse, l'extérieur doit passer par le PC pour avoir accès à la VM
  • Redirection de port à faire vous-même si besoin

Translations / Redirections :

Dans tous ces modes, ce qu'il faut bien voir, c'est qu'à partir du moment où :

  1. PC1 accède avec PC2
  2. PC2 accède à la VM
  3. vous êtes maitre de PC2

A priori tout est possible. Que la VM soit en accès par pont, nat, réseau privé hôte, etc...

Un PuTTY bien placé vous permet de faire les translations de port que vous voulez (et dans les 2 sens !).

Donc au choix :

- votre réseau est cool : vous utilisez le mode accès par point, vous avez installé une nouvelle machine sur le réseau, indépendante de l'hôte.

- votre réseau est un peu serré : NAT + redirection de port : c'est votre PC qui expose des ports qui seront redirigées vers la VM (mais alors attention aux configuration antivirus et firewall du PC du coup).

 

Le reste, c'est plus pour des configurations particulières :

- Réseau privé hôte : si votre accès par point est refusé et que vous voulez accéder "pour de vrai" à une autre VM 

- Réseau NAT : votre plage réseau local est déjà occupée.

 

Retour au problème :

Je suis passé d'un réseau "cool" à "un peu serré" avec protection des prises, le temps de trouver le paramétrage qui va bien, j'avais bloqué toutes les prises réseaux de la salle de réunion.

+

La question : "est-ce que la redirection du port en mode NAT se fait à chaud ?" (et la réponse est OUI).

+

J'utilise CentOS qui désactive la carte eth0 : le temps de tester les différentes options sous virtualbox...

 

Ca m'a pris un peu de temps (raisonnable... :)), mais ça a marché.

 

Fil RSS des articles de cette catégorie