Tag: DNS

Créer un enregistrement BIMI pour afficher votre logo dans vos emails clients et prospects

14 March 202213 juillet 2021 by Matt Biscay · Lecture: 8 minutes

Les Brand Indicators for Message Identification (BIMI) – indicateurs de marque pour l’identification des messages en français – sont un moyen standardisé pour les entreprises d’utiliser leur logo comme indicateur visible pour aider les destinataires d’e-mails à reconnaître et à éviter les messages frauduleux.

BIMI s’appuie sur le protocole d’authentification de messagerie DMARC pour développer la confiance avec les clients actuels et potentiels.

Avantages de l’enregistrement BIMI

En publiant votre fiche BIMI et le logo associé dans le DNS, votre marque sera facilement reconnue et approuvée par les clients actuels et futurs.

Non seulement les clients actuels et potentiels sont convaincus que vos e-mails sont légitimes, mais ils gagnent également un niveau de confiance en voyant votre logo approuvé dans leur boîte de réception.

Chaque fois qu’un client reçoit un message de votre domaine en utilisant la norme BIMI, au moins trois impressions de marque uniques potentielles sont effectuées: liste de messages, adresse e-mail dans le message et dans le message lui-même.

Plus vite votre entreprise décide d’adopter le BIMI (lorsqu’il est disponible via votre fournisseur de messagerie sortante), plus votre marque sera reconnue.

Étape 1 : mettre en place SPF, Sender-ID, DKIM et DMARC (et HTTPS)

Habituellement, les logos sont automatiquement extraits de diverses sources et organisés par les fournisseurs de clients de messagerie. En conséquence, différents logos s’affichent en fonction du client de messagerie et de l’appareil. Avec BIMI, les marques contrôlent leurs logos officiels affichés, quelle que soit la taille de la marque.

Les symboles sont un moyen succinct et efficace de communiquer des informations sur votre entreprise. Un logo est un élément important de la marque de votre entreprise et a un impact significatif sur la perception du public d’une entreprise.

En fait, un logo est l’un des investissements de marque les plus importants qu’une entreprise puisse faire. Il attire l’attention, fait une première impression forte, est le fondement de votre identité de marque, de la sécurité, est mémorable, vous sépare de la concurrence, favorise la fidélité à la marque et est attendu par votre public.

La spécification BIMI s’appuie sur les normes d’authentification de messagerie existantes telles que Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) et Domain-based Message Authentication, Reporting & Conformance (DMARC).

Les marques qui déploient correctement l’authentification des e-mails à l’aide de DMARC pourront tirer parti de BIMI. DMARC est une norme qui permet aux propriétaires de domaines (marques) de protéger leurs domaines en définissant des politiques d’authentification des e-mails.

DMARC fournit également des rapports qui aident à configurer l’authentification des e-mails à l’aide de SPF et DKIM sur toutes les sources.

Je vous conseille le tutoriel sur la mise en place de DMARC pour votre domaine, ainsi que celui sur l’authentification SPF, Sender-ID et DKIM pour tout paramétrer dans les règles de l’art.

Le domaine doit impérativement être servi en HTTPS.

Une fois toutes les sources valides identifiées et authentifiées, une politique DMARC restrictive (c’est-à-dire p=quarantine ou p=reject) peut être définie:

_dmarc IN TXT v=DMARC1; p=reject; rua=mailto:dmarc@example.com;

En utilisant cette stratégie, les propriétaires de domaine peuvent contrôler ce qu’il advient des messages non authentifiés (non approuvés), qu’ils finissent dans le spam ou qu’ils soient complètement rejetés par le fournisseur de messagerie destinataire.

DMARC aide les marques à se protéger contre divers types d’abus de domaine et d’attaques de phishing, mais courants.

En termes simples, vous souhaitez éventuellement avoir vos enregistrements DMARC avec une politique de quarantaine ou de rejet pour le domaine de votre marque, que vous implémentiez ou non BIMI.

MacOS : changer les serveurs DNS pour éviter les DNS menteurs de votre box

14 March 202224 juillet 2020 by Matt Biscay · Lecture: 2 minutes

Il m’arrive très souvent d’utiliser une connexion Orange (depuis une Livebox 4) lorsque je suis chez mes parents.

Le problème est que la Livebox possède ses propres serveurs DNS intégrés et qu’ils sont menteurs, c’est-à-dire qu’ils obéissent à des règles de filtrage et de blocage décidés par l’opérateur (ou par des décisions de justice qui concernent tous les opérateurs).

Dans le cas d’Orange, les requêtes sont automatiquement redirigées vers votre machine locale, sur localhost. Comme j’utilise mon serveur Local tourne en quasi-permanence sur ma machine, cela me donne une belle erreur 502, comme vous pouvez le voir sur cette image:

MacOS : changer les serveurs DNS pour éviter les DNS menteurs de votre box photo — Lorsque votre les DNS intégrés à votre box vous mentent, il est temps de changer!

Nous avions déjà abordé le changement des serveurs DNS de notre Freebox mais il est un peu plus délicat de demander à vos hôtes de pouvoir changer les réglages de leur box…

Il y a une solution bien plus simple que de trifouiller au fond des entrailles du routeur fruitier : il suffit d’ajouter de nouveaux serveurs de noms sur votre machine, directement dans les options de votre connexion réseau.

Modification des serveurs de noms sous MacOS

Sous MacOS, il suffit de se rendre dans Préférences Systèmes > Réseau > Avancé :

Changer les serveurs DNS de la Freebox Revolution

9 August 202028 février 2020 by Matt Biscay · Lecture: 1 minute

Ces derniers temps, il n’est pas rare de constater que le serveur DNS de Free, utilisés par la Freebox, ne permettent plus de consulter certains sites. Or, l’utilisation d’un VPN permet d’accéder à ces sites sans problèmes.

Il est donc temps de changer l’adresse des serveurs DNS de la Freebox, on ne peut décemment pas utiliser un internet bridé par un tiers sans notre consentement.

Voici la marche à suivre, cela prend environ 1 minute à modifier. Nous allons utiliser les serveurs DNS de Cloudflare pour cet article:

Rendez-vous dans la console Freebox sur http://mafreebox.free.fr

Identifiez-vous.

Rendez-vous dans Paramètres de la Freebox > DHCP.

En serveur DNS1, mettez 1.1.1.1

En serveur DNS2, mettez 1.0.0.1

En serveur DNS3, gardez le DNS de Free en redondance: 192.168.0.254

Appliquez les changements pour sauvegarder la nouvelle configuration.

Voici ce que cela donne en image:

Une autre alternative est d’utiliser les DNS de Quad9:

DNS1: 9.9.9.9
DNS2: 149.112.112.112

Et voilà, les sites auparavant bloqués sont désormais accessibles.

Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur

30 September 202129 janvier 2018 by Matt Biscay · Lecture: 9 minutes

Aujourd’hui, nous allons voir comment héberger un nouveau domaine sur le serveur, en simplifiant au maximum les procédures.

Le nom de domaine sera réservé chez OVH et le site hébergé sur notre serveur Debian. Nous allons servir le site avec NginX en HTTPS grâce à un certificat SSL fourni gratuitement par Let’s Encrypt.

Enfin, on utilisera le serveur email existant et on ajoutera la configuration OpenDKIM pour signer et authentifier tous les emails sortants du domaine.

Nom de domaine

J’achète mes noms de domaine chez OVH parce que le prix est relativement raisonnable (comparé à mon ancien registrar).

Au moment de la commande, faites pointer le nouveau domaine vers les DNS du serveur.

Si votre serveur n’est pas chez OVH, il suffit d’aller dans Domaines > Serveurs DNS et de renseigner le DNS primaire et secondaire de votre serveur.

Configuration DNS dans BIND

Une fois le domaine commandé, si vous vous rendez dans le Manager OVH, vous vous rendrez compte que le bouton DNS est en rouge : c’est normal puisqu’il nous faut paramétrer notre nouveau domaine dans BIND, notre serveur de noms.

On édite la configuration de BIND :

nano /etc/bind/named.conf.local

et on lui indique que nous créons une nouvelle zone :

zone "example.com" {
        type master;
        file "/etc/bind/example.com.hosts";
        allow-query { any; };
};Code language: JavaScript (javascript)

On crée maintenant notre fichier de zone:

nano /etc/bind/example.com.hosts

$ttl 84600
$ORIGIN example.com.

@       IN      SOA     XXXXXX.kimsufi.com. root.example.net. (
                        2018012801
                        14400
                        3600
                        604800
                        84600 )

; NAMESERVERS
 IN     NS      XXXXXX.kimsufi.com.
 IN     NS      ns.kimsufi.com.

example.com.   IN      A       XXX.XXX.XXX.XXX
example.com.   IN      AAAA    4001:41d0:1:4462::1
example.com.   IN      MX      10 mail.example.net.

www.example.com.       IN      A        XXX.XXX.XXX.XXX
www.example.com.       IN    AAAA    4001:41d0:1:4462::1
www       IN A          XXX.XXX.XXX.XXXCode language: PHP (php)

Ps: example.net est le domaine principal du serveur.

Pous vérifions la configuration BIND:

named-checkconf -z

et nous redémarrons BIND pour prendre en compte nos changements et activer notre nouveau fichier de zone:

service bind9 restart

Vous pouvez vérifier votre configuration DNS à l’aide de l’outil ZoneMaster.

Configuration du bloc serveur sous NginX

On commence par créer le répertoire qui va accueillir les fichiers du site et on lui attribue les bons droits:

mkdir -p /home/example/public_html
chown -R www-data:www-data /home/example/public_html
chmod 755 /home/example/public_html

On crée également un fichier index.php à la racine du site pour éviter une erreur 403 plus tard lors de la génération du certificat SSL :

echo "<!--?php echo 'hello world. Domain activated.'; ?-->" >> /home/example/public_html/index.phpCode language: HTML, XML (xml)

On crée maintenant le répertoire de cache du site, toujours avec les bons droits:

mkdir -p /home/nginx-cache/example
chown -R www-data:www-data /home/nginx-cache/example
chmod 755 /home/nginx-cache/example

Voici le server block de départ, en HTTP simple :

server {
       listen         80;
       listen    [::]:80;
       server_name    example.com www.example.com;
       #return         301 https://$server_name$request_uri;
        root /home/example/public_html;
        index index.php index.html;
}Code language: PHP (php)

On active le site :

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

On teste la configuration de NginX et on redémarre le service:

nginx -t
service nginx restart

On crée maintenant le certificat SSL avec Let’s Encrypt :

certbot certonly --webroot -w /home/example/public_html -d example.com -d www.example.com

Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND

4 April 202220 avril 2016 by Matt Biscay · Lecture: 9 minutes

Notre serveur de mail possède une identification SPF, Sender-ID et DKIM et est sécurisé par un certificat TLS. Nous allons aujourd’hui voir comment lui adjoindre l’authentification DMARC.

Aux origines de l’authentification des emails

Les technologies d’authentification des emails SPF et DKIM ont été développées afin de fournir une plus grande assurance sur l’identité de l’expéditeur d’un message.

L’adoption de ces technologies a augmenté régulièrement mais le problème des emails frauduleux et trompeurs n’a pu etre réglé.

Il existe une multitude d’environnements et de systèmes différents pour envoyer des emails, et on fait souvent appel à des applications tierces pour gérer les envois.

S’assurer que chaque message peut être authentifié avec SPF ou DKIM n’est pas une mince affaire étant donné que le traitement des emails se fait en temps réel.

Si le propriétaire d’un domaine envoie un groupe de message et que certains peuvent être authentifiés et d’autres non, alors les récipiendaires de ces messages sont obligés de faire la distinction entre les messages légitimes qui ne sont pas authentifiés et les messages frauduleux qui ne sont pas authentifiés non plus.

Par nature, les algorithmes de spam sont sujets aux erreurs et doivent évoluer constamment pour répondre aux nouvelles tactiques des spammeurs. Au final, certains messages frauduleux parviendront toujours à atteindre la boite de réception du destinataire final.

Le seul moyen de résoudre ces problèmes est de partager l’information entre l’expéditeur et le destinataire. Les destinataires vont fournir des informations sur leur infrastructure d’authentification des messages et les expéditeurs vont dire aux destinataires quoi faire lorsqu’un message reçu n’est pas authentifié.

En 2007, Paypal a été pionnier dans cette approche et a construit un système avec l’aide de Yahoo! Mail puis Gmail. Les résultats ont été très probants, menant à une baisse du nombre des emails frauduleux qui se faisaient passer comme venant des serveurs de Paypal acceptés par les destinataires.

DMARC : un protocole d’authentification email

DMARC, qui signifie Domain-based Message Authentication, Reporting and Conformance est un protocole d’authentification email qui se base sur les protocoles SPF et DKIM – maintenant largement déployés – en ajoutant une fonction de rapport qui permet aux expéditeurs et destinataires d’améliorer et vérifier la protection du domaine contre les emails frauduleux.

DMARC se base sur le processus d’authentification des messages entrants et aide les destinataires à déterminer si les message est “aligné” avec ce que le destinataire connaît de l’expéditeur. Sinon, DMARC inclut une manière de gérer les messages “non-alignés”.

Voici le principe de fonctionnement de DMARC :

Serveur dédié : ajouter l'authentification DMARC à Postfix et Bind9 photo

Il est important de noter que DMARC est basé à la fois sur les spécifications de DKIM (DomainKeys Identified Mail) et SPF (Sender Policy Framework) qui sont toujours en cours de développement par l’IETF.

8 règles d'or pour un bon déploiement de DNSSEC et DANE photo

8 règles d’or pour bien déployer DNSSEC et DANE

29 March 202207 décembre 2015 by Matt Biscay · Lecture: 4 minutes

Vous avez sécurisé votre domaine avec DNSSEC et DANE ? Très bien ! Il a cependant quelques petites choses à garder à l’esprit pour anticiper les difficultés et bien gérer la maintenance.

De la rigueur dans la gestion des enregistrements DS (DNSSEC) et TLSA (DANE)

Les enregistrements au niveau du DNS sont à manipuler avec précaution, ce ne sont pas le genre de choses que l’on peut configurer une bonne fois pour toute. On ne publie pas des enregistrements DS (DNSSEC) et TLSA (DANE) par effet de mode.

Les zones DNSSEC doivent être signées régulièrement et les enregistrements TLSA mis à jour en cas de changement de certificats TLS. Si la maintenance n’est pas assurée correctement, le domaine risque d’être injoignable.

Automatiser la signature de la zone DNS

Vous devez absolument mettre en place un crontab qui signe votre zone DNS automatiquement et vous informe du bon fonctionnement de votre zone.

Mettre à jour les enregistrements TLSA avant la chaine de certificat du serveur

Vous devez absolument mettre à jour les enregistrements TLSA avant de mettre à jour la chaine de certificat du serveur (déploiement de nouvelles clés ou utilisation d’un nouveau certificat TLS issu par une autorité de certification).

Lorsque vous mettez à jour votre certificat, vous devez garder les anciens enregistrements TLSA dans votre fichier de zone et ajouter les nouveaux enregistrements TLSA.

Les anciens et les nouveaux doivent donc coexister, le temps que les enregistrements DNS soient mis à jour, après quelques TTLS (quelques jours seulement).

Par exemple, la key1 est déployée initialement sur le serveur :

_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

On ajoute la nouvelle clé key2 pendant quelques jours, juste derrière la key1 :

_25._tcp.mail.example.com. IN TLSA 3 0 1 
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

Après le déploiement de la key2, on supprime la key1 :

_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

Serveur dédié : mise en place du protocole DANE

12 September 202102 décembre 2015 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, je vous montre comment mettre en place le protocole DANE sur votre serveur.

En pré-requis, votre domaine doit:

Cela prend environ 20 minutes à configurer, auxquelles s’ajouteront quelques heures afin que la résolution DNS avec les changements soit complète.

DANE : l’authentification TLS sans autorité de certification

DANE (DNS-based Authentication of Named Entities) est un protocole qui permet aux certificats X.509 – généralement utilisés pour TLS – d’être liés au DNS en s’appuyant sur DNSSEC.

L’IETF a défini DANE dans la RFC 6698 comme un moyen d’authentifier des clients TLS et des serveurs sans passer par une autorité de certification (AC).

Cette démarche s’enregistre dans une logique de sécurisation des accès clients-serveurs pour d’une part sécuriser les requêtes DNS effectuées depuis les postes clients au travers des protocoles/mécanismes DNSSEC et TLS, et d’autre part mieux sécuriser les accès chiffrés des clients vers le serveurs.

Le chiffrement TLS est actuellement basé sur des certificats qui sont délivrés par des Autorités de Certification (AC ou Certificate Authority, CA en anglais).

Or, ces dernières années ont vu un certain nombre d’AC qui ont souffert de sérieux problèmes d’intrusions et de failles de sécurité, ce qui a permis la délivrance de certificats pour des sites très connus à des personnes qui ne détenaient pas ces domaines.

Faire confiance à un large nombre d’Autorités de Certification peut être un problème, étant donné que n’importe laquelle d’entre elles, si elle est compromise, pourrait délivrer un certificat pour n’importe quel nom de domaine.

Le protocole DANE permet à l’administrateur d’un nom de domaine de certifier les clés utilisées dans les clients ou serveurs TLS de ce domaine en les insérant au niveau du DNS.

DANE a donc besoin que les enregistrements DNS soient signés avec DNSSEC pour que son modèle de sécurité fonctionne.

De surcroit, DANE permet à l’adminstrateur du domaine de spécifier quelle autorité de certification est autorisée à délivrer des certificats pour une ressource particulière, ce qui résoud le problème des autorités de certification qui sont capables de délivrer des certificats pour n’importe quel nom de domaine.

Serveur dédié : mise en place du protocole DANE photo 3

Les enregistrements TLSA

DANE utilise des enregistrements TLSA, qui incluent l’empreinte du certificats X.509 qui protège un nom de domaine.

Nous devons tout d’abord générer cet enregistrement TLSA en nous basant sur le certificat installé sur notre serveur. Ensuite, cet enregistrement TLSA sera ajouté à notre zone DNS.

Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine

16 August 202426 octobre 2015 by Matt Biscay · Lecture: 15 minutes

Aujourd’hui, nous allons mettre en place DNSSEC afin d’ajouter une couche de sécurité supplémentaire dans la gestion des DNS de notre domaine.

Principe de fonctionnement du DNS

Le DNS (Domain Name System) est un maillon clé du fonctionnement d’Internet car la quasi-totalité des services en ligne utilisent des noms de domaine à un moment ou à un autre.

Le DNS est organisé sous la forme d’une arborescence inversée, avec une « racine » dont dépendent les différentes « branches ».

Au premier niveau de l’arborescence se trouvent les « Top Level Domains » (TLD) ou domaines de premier niveau, comme les .fr, .com, .net etc.

Au second niveau, nous avons les noms de domaine « classiques » comme « skyminds.net ».

Fonctionnant comme une base de données distribuée sur des millions de machines, le DNS repose sur des interactions entre ces machines permettant d’identifier celle qui est la plus susceptible de pouvoir répondre à la requête d’un internaute.

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo 2

Dans l’exemple ci-dessus, l’utilisateur veut se connecter au site http://www.wikipedia.fr. Il envoie sa requête via son navigateur. Celle-ci est reçue par un serveur dit « résolveur » qui a pour première mission d’identifier la machine sur laquelle est installé le nom de domaine wikipedia.fr.

Le résolveur s’adresse d’abord à la « racine » du DNS, qui lui indique quels sont les serveurs « faisant autorité » (c’est-à-dire compétents) pour .fr puisque le nom de domaine est en .fr.

Dans un second temps, les serveurs du .fr indiquent à leur tour au résolveur que le nom de domaine wikipedia.fr est hébergé sur tel serveur.

Celui-ci est alors en mesure d’indiquer au navigateur l’adresse IP du serveur web hébergeant les contenus du site web www.wikipedia.fr.

Ce schéma se vérifie quel que soit le site web auquel on souhaite accéder.

DNSSEC : authentifier l’origine et l’intégrité des données

DNSSEC, acronyme de Domain Name System Security Extensions, désigne un ensemble défini d’extensions de sécurité du protocole DNS, standardisé par l’IETF dans la RFC 4033.

Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim

6 February 202423 septembre 2014 by Matt Biscay · Lecture: 8 minutes

Cela fait quelques années maintenant que mon serveur tourne et je trouvais le serveur de mail (postfix) bien fonctionnel plutôt bien jusqu’à ce que je reçoive des messages de la part de Gmail comme quoi les emails envoyés par le site sont considérés comme spam!

Et c’est à ce moment que l’on réalise qu’être bloqué par son fournisseur email, ce n’est pas cool du tout : à chaque fois qu’un nouveau commentaire est publié et que quelqu’un y est abonné, l’erreur se déclenche et le mail part en mail delivery service.

Voici le message type que l’on reçoit de Gmail dans ce cas:

Final-Recipient: rfc822; ***@gmail.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit
    https://support.google.com/mail/answer/81126 to review our Bulk Email Senders Guidelines. Code language: JavaScript (javascript)

Lorsque l’on monte un serveur email, rien n’est sécurisé par défaut. Avec tout le spam en circulation, il y a des entêtes à ajouter lors de l’envoi pour que le courrier ne soit pas considéré comme indésirable :

Il est donc temps de sécuriser un peu notre serveur de mail.

Étape 1 : diagnostics

Sur le serveur dans le terminal, on envoie un mail de test :

mail  check-auth@verifier.port25.comCode language: CSS (css)

Résultat:

==========================================================
Summary of Results
==========================================================
SPF check:          softfail
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    softfail
SpamAssassin check: ham

Du fail et du neutral, ce n’est pas trop bon! Nous allons commencer par activer SPF et Sender-ID.

Étape 2 : ajouter SPF et Sender-ID à BIND

Nous allons donc ajouter l’authentification SPF (Sender Policy Framework) à notre enregistrement DNS. On édite le fichier de configuration BIND de notre domaine :

nano /etc/bind/skyminds.net.hosts

Et on y ajoute à la fin du fichier :

;SPF
skyminds.net. IN TXT "v=spf1 ip4:IP4SERVEUR mx -all"
skyminds.net. IN SPF "v=spf1 ip4:IP4SERVEUR mx -all"
mail.skyminds.net. IN  TXT  "v=spf1 ip4:IP4SERVEUR a -all"
mail.skyminds.net. IN  SPF  "v=spf1 ip4:IP4SERVEUR a -all"Code language: JavaScript (javascript)

Remplacez IP4SERVEUR par l’IPv4 de votre serveur et skyminds.net par votre nom de domaine. Enregistrez le fichier et relancez BIND :

/etc/init.d/bind9 restart

On renvoie un mail de test :

mail  check-auth@verifier.port25.comCode language: CSS (css)

Nouveau résultat :

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    pass
SpamAssassin check: ham

Pas mal, on vient d’activer le SPF et le Sender-ID en 2 minutes !

Étape 3 : installation de l’authentification DKIM

DKIM (DomainKeys Identified Mail) est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un courrier électronique : DKIM fonctionne par signature cryptographique du corps du message et d’une partie de ses en-têtes.

Une signature DKIM vérifie donc l’authenticité du domaine expéditeur et garantit l’intégrité du message. Idéal pour lutter contre le spam.

1. On installe opendkim :

apt-get install opendkim opendkim-toolsCode language: JavaScript (javascript)

Et on édite le fichier de configuration:

nano /etc/opendkim.conf

On supprime tout le contenu de ce fichier et on met :

 # Enable Logging
Syslog yes
SyslogSuccess yes
LogWhy yes

# User mask
UMask 002

# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer and the verifier)
OversignHeaders From

# Our KeyTable and SigningTable
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable

# Trusted Hosts
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

# Hashing Algorithm
SignatureAlgorithm rsa-sha256

# Auto restart when the failure occurs. CAUTION: This may cause a tight fork loops
AutoRestart Yes
DNSTimeout  5

# Set the user and group to opendkim user
UserID opendkim:opendkim

# Specify the working socket
Socket inet:12345@localhost

Canonicalization relaxed/relaxedCode language: PHP (php)

2. On édite la configuration par défaut d’opendkim:

nano /etc/default/opendkimCode language: JavaScript (javascript)

Avec :

# Command-line options specified here will override the contents of
# /etc/opendkim.conf. See opendkim(8) for a complete list of options.
#DAEMON_OPTS=""
#
# Uncomment to specify an alternate socket
# Note that setting this will override any Socket value in opendkim.conf
#SOCKET="local:/var/run/opendkim/opendkim.sock" # default
#SOCKET="inet:54321" # listen on all interfaces on port 54321
SOCKET="inet:12345@localhost" # listen on loopback on port 12345
#SOCKET="inet:12345@192.0.2.1" # listen on 192.0.2.1 on port 12345Code language: PHP (php)

3. On crée un nouveau répertoire pour notre clé et on assigne les droits à l’utilisateur opendkim, du groupe opendkim:

mkdir -pv /etc/opendkim/skyminds.net/
chown -Rv opendkim:opendkim /etc/opendkim
chmod go-rwx /etc/opendkim/*

Ensuite, on crée une paire de clés pour chaque domaine :

cd /etc/opendkim/skyminds.net/
opendkim-genkey -r -h rsa-sha256 -d skyminds.net -s mail -b 4096
mv -v mail.private mail
chown opendkim:opendkim *
chmod u=rw,go-rwx * Code language: PHP (php)

Cela nous crée 2 fichiers : un fichier mail (clé privée) et un fichier mail.txt qui contiendra notre clé publique.

4. On ajoute notre clé publique à l’enregistrement DNS du domaine dans BIND:

nano /etc/bind/skyminds.net.hosts

On y copie notre clé publique (/etc/opendkim/skyminds.net/mail.txt) à la fin du fichier :

;DKIM
_domainkey.skyminds.net. IN TXT "t=y; o=-;"
mail._domainkey.skyminds.net. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6YG5lJXmZxgz1eFprQfEV8oqUjYceMNPctuhi/Fo+oE+4oeDwMTDyPJcGCuJMp2XZxL2X3a8/Q9g3StekiHWqPehY7cyrnYZg6ttTCdbJYGAc/t0rVCKut/2baiGw9lcMq5sbUG9YywEEI/rN4Fu0PCU1A6BkqtNAepPhDwVRAQIDAQAB; t=s"; ----- DKIM key mail for skyminds.net
_adsp._domainkey.skyminds.net. IN TXT "dkim=unknown"Code language: JavaScript (javascript)

On enregistre le fichier et on relance BIND :

/etc/init.d/bind9 restart

5. On associe les domaines avec les clés :

nano  /etc/opendkim/KeyTable

La syntaxe du fichier est la suivante :
KeyID Domain:Selector:PathToPrivateKey

Nous ajoutons donc :

skyminds.net skyminds.net:mail:/etc/opendkim/skyminds.net/mailCode language: JavaScript (javascript)

6. On édite ensuite la table des signatures :

nano /etc/opendkim/SigningTable

à laquelle on ajoute :

*@skyminds.net skyminds.netCode language: CSS (css)

7. On définit les domaines considérés comme trusted :

nano /etc/opendkim/TrustedHosts

Avec :

127.0.0.1
localhost
ns.kimsufi.com
skyminds.netCode language: CSS (css)

Il ne faut pas oublier d’ajouter le DNS de votre hébergeur (ns.kimsufi.com chez moi).

8. On applique maintenant les bons droits à nos fichiers :

chown opendkim:opendkim /etc/opendkim/KeyTable
chown opendkim:opendkim /etc/opendkim/SigningTable
chown opendkim:opendkim /etc/opendkim/TrustedHosts

9. On édite maintenant la configuration Postfix :

nano /etc/postfix/main.cf

Et on rajoute :

# DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12345
non_smtpd_milters = $smtpd_miltersCode language: PHP (php)

On redémarre bind, opendkim et postfix pour vérifier que tout va bien :

/etc/init.d/bind9 restart
/etc/init.d/opendkim restart
/etc/init.d/postfix restart

10. On vérifie qu’opendkim est bien lancé sur le serveur :

ps aux | grep dkim
netstat -tanp | grep dkim

Étape 4 : tests et vérifications

Il faut maintenant attendre que la propagation DNS prenne effet, cela peut prendre quelques heures.

Vous pouvez lancer un test DKIM ici : http://www.brandonchecketts.com/emailtest.php

Vérifiez les erreurs mail dans les logs :

tail -f /var/log/mail.logCode language: JavaScript (javascript)

Envoyez-vous un email via le terminal. Voici ce que vous devriez obtenir :

Étape 5 : optimiser la vitesse d’envoi

Quelques jours après la réalisation et la mise en place du tutoriel, je me suis aperçu que Gmail grognait toujours à cause de la vitesse à laquelle étaient envoyés les emails, notamment lorsque beaucoup de gens sont abonnés aux commentaires : en cas de nouveau commentaire, une flopée de notifications partent au même moment – ce qui déclenche le message d’erreur chez Gmail.

Pour améliorer cela, on édite à nouveau le fichier de configuration postfix :

nano /etc/postfix/main.cf

Et on y rajoute :

# Matt : NOT TOO FAST COWBOY!
# This means that postfix will up to two concurrent
# connections per receiving domains. The default value is 20.
default_destination_concurrency_limit = 2
# Postfix will add a delay between each message to the same receiving domain.
default_destination_rate_delay = 5s
# Limit the number of recipients of each message.
# If a message had 20 recipients on the same domain, postfix will break it out
default_extra_recipient_limit = 3Code language: PHP (php)

Cela se connecte au maximum avec 2 connexions par domaine, avec un délai de 5 secondes entre chaque message s’ils sont envoyés au même domaine et on envoie par tranche de 3 messages. Un peu alambiqué mais cela semble satisfaire Google.

Voilà, c’est fini. Les messages de votre serveur de mail devraient maintenant être un peu plus acceptés dans les boîtes de réception !

Serveur dédié : mise en place de l’IPv6

26 August 202116 février 2014 by Matt Biscay · Lecture: 4 minutes

IPv6 (Internet Protocol version 6) est un protocole réseau sans connexion de la couche 3 du modèle OSI.

Grâce à des adresses de 128 bits au lieu de 32 bits, IPv6 dispose d’un espace d’adressage bien plus important qu’IPv4.

Cette quantité d’adresses considérable permet une plus grande flexibilité dans l’attribution des adresses et une meilleure agrégation des routes dans la table de routage d’Internet.

La traduction d’adresse, qui a été rendue populaire par le manque d’adresses IPv4, n’est plus nécessaire.

Fin 2013, on estime le déploiement d’IPv6 à 2 %, et ce en dépit d’appels pressants à accélérer la migration, l’épuisement des adresses IPv4 publiques disponibles étant imminent.

Histoire d’assurer la pérennité de la connexion de notre serveur Kimsufi, voici comment mettre en place l’IPv6. Cela prend à peu près 15 minutes.

Etape 1 : récupérer l’adresse IPv6

Méthode graphique : identifiez-vous dans le Manager OVH et allez dans Serveur Dédié > Récapitulatif. Vous devriez obtenir quelques informations sur la connexion de votre Kimsufi, comme ceci :

Méthode “terminal” : un autre moyen de trouver l’IPv6 est de lancer le terminal et taper la commande ifconfig :

ifconfig

Notez bien l’adresse IPv6 du serveur, nous allons nous en servir dans la prochaine étape.

Créer une redirection No-IP

10 March 202409 octobre 2012 by Matt Biscay · Lecture: 2 minutes

Plusieurs personnes m’ont demandé une alternative à DynDNS, qui est passé à un modèle exclusivement payant pour les nouveaux comptes.

Sept ans après l’article Créer une redirection DynDNS, je vous propose donc un tuto pour créer une redirection No-IP.

La redirection No-IP vous permettra d’avoir une adresse facile à retenir, malgré vos changements d’IP.

La création d’une redirection prend moins de 5 minutes.

Etape 1 : création du compte No-IP

Créez votre compte gratuitement sur No-IP. Il vous suffit de remplir vos identifiants, mot de passe et adresse email puis de valider votre compte en cliquant sur le lien que vous recevrez par mail (pensez à regarder dans le dossier spam, il peut s’y trouver).

Une fois dans l’espace membre, vous obtenez cet écran :

BIND9 : supprimer le message "success resolving after reducing the advertised EDNS UDP packet size to 512 octets" des logs photo

BIND9 : résoudre l’erreur “ignoring out-of-zone data”

8 April 202210 mai 2012 by Matt Biscay · Lecture: 2 minutes

Bien configurer BIND9 pour que tout fonctionne correctement n’est pas vraiment intuitif et le parcours est semé d’embûches.

Sur mon ancien serveur OVH, j’ai connu l’erreur suivante pendant des mois :

/etc/bind/skyminds.net.hosts:15: ignoring out-of-zone data (ksXXXXXXX.kimsufi.com)

Alors bon, cela n’empêche pas du tout le serveur DNS de faire son travail mais c’est quand même un peu gênant de savoir que la configuration n’est pas optimale.

Voici comment y remédier.

Problème : BIND renvoie l’erreur “ignoring out-of-zone data”

Lors d’un checkconf BIND :

named-checkconf -z

Vous obtenez ceci :

/etc/bind/db.skyminds.net:15: ignoring out-of-zone data (ks3094174.kimsufi.com)
zone skyminds.net/IN: loaded serial 2011020911
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1

Ce qui n’est pas vraiment optimal.