Serveur dédié: gérez comptes et alias email avec PostfixAdmin photo

Serveur dédié: gérez comptes et alias email avec PostfixAdmin

Si vous possédez et gérez votre propre serveur email, il peut être très intéressant de proposer des comptes emails et des alias pour vos utilisateurs.

J’ai écrit il y a quelques années un tutoriel qui faisait cela à la main avec une base SQL et des domaines virtuels mais il y a aujourd’hui beaucoup plus simple avec PostfixAdmin.

PostfixAdmin

PostfixAdmin est une interface web open-source qui permet de gérer des comptes mails, des domaines et des alias sur un serveur mail Postfix.

il s’intègre avec

  • Postfix
  • un server IMAP/POP3 comme Dovecot ou Courier
  • une base de données (sqlite, mysql, postgresql)
  • Fetchmail (optionnel)

Il est très utile pour créer des alias à la volée ou des comptes mail rapidement.

Création du sous-domaine

Je trouve cela plus simple de créer un sous-domaine pour ce type d’application. Dans votre gestionnaire DNS, il suffit d’ajouter un enregistrement de type A:

XXXXX.EXAMPLE.COM IN A xxx.xxxx.xxx.xxx

XXXXX est votre sous-domaine sur EXAMPLE.COM et xxx.xxx.xxx.xxx l’adresse IPv4 de votre serveur.

Création de la base de données

Nous utilisons MySQL/MariaDB pour postfix donc on s’identifie sur la console mysql :

mysql -u root -p 

[MOT DE PASSE ROOT]

Et on lance:

CREATE DATABASE postfix; 
CREATE USER 'mymailadmin'@'localhost' IDENTIFIED WITH mysql_native_password BY '1nyXI7Y)$spmslgz4HhdE4Lc_vm&)Gh!MsZFf64645fek'; 
GRANT ALL PRIVILEGES ON postfix.* TO 'mymailadmin'@'localhost'; 
FLUSH PRIVILEGES; EXIT;

Nous avons donc un nouvel utilisateur et une nouvelle base de données, spécifiques pour PostfixAdmin.

Configuration NginX pour PostfixAdmin

On crée un nouveau server block spécifique à PostfixAdmin:

nano /etc/nginx/sites-available/postfixadmin.conf

Lire la suite

Postfix : résoudre l'avertissement

Postfix : résoudre l’avertissement “Untrusted TLS connection established”

Si vous possédez votre propre serveur email, géré avec Postfix, vous pouvez parfois obtenir l’avertissement suivant, lorsque vous utilisez un certificat SSL/TLS :

postfix/smtp[13461]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.166.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

La solution est très simple, il suffit d’éditer le fichier main.cf de Postfix :

nano /etc/postfix/main.cf

Et on y ajoute:

smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs

Sauvegardez le fichier puis relancez Postfix :

service postfix restart

Envoyez un mail depuis le serveur, vous devriez maintenant obtenir le graal :

postfix/smtp[7243]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c08::1a]:25: TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

Et voilà, authentifié en TLS pour l’envoi de mail avec Postfix.

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

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

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.

Lire la suite

Fail2Ban: protéger Postfix contre les attaques AUTH DoS photo

Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO

Aujourd’hui, Jac m’envoie un message pour m’informer que sa redirection email ne fonctionne plus.

Je lance donc un terminal et vérifie les logs de Postfix, qui chargent des dizaines de lignes d’erreurs de ce type:

Dec 15 16:30:33 mail postfix/smtpd[5912]: connect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5912]: lost connection after AUTH from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5912]: disconnect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: connect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: lost connection after AUTH from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: disconnect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]

Comme vous pourvez le constater, ça débite et ça impacte forcément les ressources du système. Voyons donc comment nous pouvons y mettre un terme.

Fail2Ban: protéger Postfix contre les attaques AUTH DoS photo

Pré-requis : fail2ban

Nous allons utiliser fail2ban, un compagnon très utile pour surveiller les logs et analyser les comportements néfastes à l’aide d’expressions régulières.

Je vous invite à relire le guide d’installation de fail2ban.

Nouvelle définition dans fail2ban : postfix-auth

Nous ajoutons donc une nouvelle définition, [postfix-auth], dans notre fichier jail.local:

nano /etc/fail2ban/jail.local

On l’ajoute à la fin des déclarations pour les serveurs mails :

[postfix-auth]
enabled     = true
filter      = postfix.auth
action      = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
#           sendmail[name=Postfix, dest=you@mail.com]
logpath     = /var/log/mail.log

Je désactive volontairement l’envoi des notifications, ce serait un comble.

Lire la suite

Postfix : résoudre l'erreur SASL

Postfix : résoudre l’erreur SASL “_sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql”

postfix-logo

Il y a quelques mois, j’ai aperçu quelques messages d’erreurs récurrents dans les fichiers logs du serveur de mail Postfix, concernant SASL.

Voici un extrait de ces messages:

Oct 10 11:35:05 mail postfix/smtpd[18553]: sql_select option missing
Oct 10 11:35:05 mail postfix/smtpd[18553]: auxpropfunc error no mechanism available
Oct 10 11:35:05 mail postfix/smtpd[18553]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql

La solution est toute simple – commencez par éditer le fichier de configuration de Postfix:

nano /etc/postfix/main.cf

Puis commentez la ligne qui commence par smtpd_sasl_path. Chez moi, cela donne :

#smtpd_sasl_path = private/auth

Et enfin, il suffit de relancer tous les services relatifs à l’identification SASL ainsi que Postfix :

find /etc/init.d/ | grep courier | while read line; do $line restart; done
service saslauthd restart
service postfix restart

Et voilà, plus de messages d’erreur dans les logs.

Postfix : résoudre l'erreur SASL

Postfix : résoudre l’erreur “Untrusted TLS connection established to Gmail”

postfix-logo

En vérifiant les logs de mon serveur mail, je me suis aperçu que, malgré mon certificat, la connexion du serveur à un serveur sortant n’était pas entièrement chiffrée.

Voici comment remédier à ce problème.

Postfix : “untrusted connection SMTP”

Concrètement, voici la transcription du log d’une connexion SMTP dite “untrusted connection SMTP” :

postfix/cleanup: message-id=<9@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25, delay=1.5, delays=0.12/0.06/0.55/0.73, dsn=2.0.0, status=sent (250 2.0.0 OK 1430771763 z16si1523612wjr.190 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com>

Comme on peut le constater, notre connexion TLS n’est pas chiffrée de bout en bout :

Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

Solution : ajouter la directive smtp_tls_CAfile

J’ai pour habitude de mettre les mêmes valeurs pour les directives smtp_* et smtpd_* mais dans ce cas précis, il faut modifier la valeur de la directive smtp_tls_CAfile.

On édite le fichier de configuration de Postfix :

nano /etc/postfix/main.cf

On modifie smtp_tls_CAfile pour pointer vers le fichier /etc/ssl/certs/ca-certificates.crt:

###
# Trusted TLS connection to gmail-smtp
# by Matt 
# https://www.skyminds.net
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
###

et on redémarre Postfix :

service postfix restart

Trusted TLS connection established

Après un envoi de test, voici ce que nous donnent les logs:

postfix/cleanup: message-id=<a@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Trusted TLS connection established to gmail-smtp-in.l.google.com[74.125.136.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.136.27]:25, delay=1.1, delays=0.12/0.07/0.31/0.58, dsn=2.0.0, status=sent (250 2.0.0 OK 1430772064 jt5si24487408wjc.48 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com></a@mail.example.com>

Et voilà, connexion vers les serveurs SMTP chiffrée et validée comme trusted!

debian-8-jessie

Serveur dédié : la mise à jour vers Debian 8 Jessie

Hier soir, j’ai mis à jour le serveur : nous passons de Debian 7.8 (wheezy) à 8.0 (jessie).

Tout s’est plutôt bien passé, il y a eu environ 10 minutes de downtime, le temps que je comprenne ce qui avait changé, notamment dans la configuration Apache et celle de Postfix.

Voici un petit compte-rendu de la mise à jour.

Mise à jour des dépôts

On édite notre fichier source APT :

nano /etc/apt/sources.list

et on remplace toutes les occurences de wheezy par jessie.

Chez moi, cela donne :

# DEBIAN
deb http://mirror.ovh.net/debian/ stable main contrib non-free
deb-src http://mirror.ovh.net/debian/ stable main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

# mod security
deb http://ftp.debian.org/debian/ jessie-backports main

Préparation à la mise à jour de Debian

J’ai commencé par vérifier qu’aucun paquet n’était à moitié installé :

dpkg --audit

ou en attente :

dpkg --get-selections | grep 'hold

Rien? Tout va bien, on continue et on simule une installation avec :

apt-get -o APT::Get::Trivial-Only=true dist-upgrade

Le résultat est une longue liste de paquets, suivie du message suivant:

439 upgraded, 192 newly installed, 5 to remove and 1 not upgraded.
Need to get 275 MB of archives.
After this operation, 259 MB of additional disk space will be used.
E: Trivial Only specified but this is not a trivial operation.

Nos sauvegardes sont faites, on se lance.

Mise à jour Debian

On rafraichit les dépôts et on lance l’installation:

apt-get update && apt-get upgrade

On obtient un laïus avec ce qui change. J’aperçois plusieurs pages sur Apache, on y reviendra. Cela dure à peu près une dizaine de minutes, bien que je n’ai pas vraiment minuté.

Une fois l’installation terminée, on résout les dépendances et les paquets manquants avec :

apt-get dist-upgrade

Je lance le site pour voir : paf, erreur 403.

Lire la suite

Postfix : résoudre l'erreur SASL

Postfix : résoudre l’erreur “close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)”

postfix-logo

En jetant un oeil sur les logs du serveur du mail, je me suis aperçu que le même message d’erreur revenait à intervalles réguliers, entre quelques statistiques.

Il s’agit de Postfix qui donne le message suivant :

close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)

Selon le créateur de Postfix, ce n’est pas un bug mais juste un message sans conséquence. N’empêche que l’on peut s’en passer facilement.

Solution : ajouter address_verify_map à la configuration Postfix

Cette erreur survient lorsque le fichier de configuration Postfix n’est pas tout à fait complet.

Lire la suite

Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy photo

Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy

Aujourd’hui, on va s’atteler à sécuriser le serveur de mail, géré par Postfix et Courier, pour utiliser notre certificat SSL et en ajoutant le Perfect Forward Secrecy.

Ce tutoriel part du principe que votre serveur tourne sous Debian et que vous avez suivi le tutoriel précédent sur Postfix avec gestion d’utilisateurs virtuels, c’est-à-dire que le serveur de mail doit déjà être opérationnel.

Vérification du fonctionnement du serveur de mail

On commence par vérifier que le serveur est capable d’envoyer des mails avec :

echo "test" | mail -s testsubject user@example.com

Si le mail est reçu, passez à l’étape suivante.

Configuration du certificat SSL

Nous allons concaténer la clé et le certificat pour Courier :

cd /etc/ssl
cat skyminds.net.key  skyminds_net.crt >> courier-key-crt-dh.pem

et on va y inclure un échange de clés Diffie-Hellman :

openssl dhparam 2048 >> courier-key-crt-dh.pem

On ajoute une autre clé DH en 2048 bits:

openssl gendh -out /etc/postfix/dh_2048.pem -2 2048

L’échange de clés Diffie-Hellman – du nom de ses auteurs Whitfield Diffie et Martin Hellman – est une méthode par laquelle deux personnes nommées conventionnellement Alice et Bob peuvent se mettre d’accord sur un nombre (qu’ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu’une troisième personne appelée Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges. Cela sécurise un peu plus l’échange.

Lire la suite

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

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

dkim-spf-200

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. 

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 :

dkim-spf-schema

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.com

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"

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.com

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-tools

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/relaxed

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

nano /etc/default/opendkim

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 12345

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 * 

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"

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/mail

6. On édite ensuite la table des signatures :

nano /etc/opendkim/SigningTable

à laquelle on ajoute :

*@skyminds.net skyminds.net

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.net

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_milters

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.log

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

dkim-spf-signed

É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 = 3

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 !

Postfix : résoudre l'erreur SASL

Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”

postfix-logo

En regardant le fichier log /var/log/mail.err, je me suis aperçu que WordPress ne m’envoyait plus les sauvegardes hebdomadaires de la base de données.

Voici les messages d’erreur des logs :

Aug  6 20:07:31 mail postfix/sendmail[6460]: fatal: www-data(33): message file too big
Aug 13 20:07:36 mail postfix/sendmail[2033]: fatal: www-data(33): message file too big
Aug 20 20:07:33 mail postfix/sendmail[30622]: fatal: www-data(33): message file too big
Aug 27 20:07:29 mail postfix/sendmail[16390]: fatal: www-data(33): message file too big

Après une rapide enquête, il se trouve que ma base de données fait plus de 8 Mo, ce qui dépasse la configuration par défaut de Postfix.

Augmenter la limite de poids des messages sous Postfix

Il nous faut donc relever la limite de poids des messages. Pour cela, il suffit d’éditer le fichier de configuration Postfix :

nano /etc/postfix/main.cf

et d’ajouter cette ligne à la fin du fichier :

message_size_limit = 51200000

Cela nous permet d’envoyer jusqu’à 50 Mo. Attention, il faut que la taille de message_size_limit soit inférieure à la taille de la boîte mail, virtual_mailbox_limit. Sur mon serveur, j’ai désactivé cette dernière :

virtual_mailbox_limit = 0

Il ne vous reste plus qu’à relancer Postfix :

/etc/init.d/postfix restart

Et voilà!

Serveur dédié : création d'un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d'utilisateurs/domaines virtuels photo 1

Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels

Aujourd’hui, nous voyons comment créer un serveur mail sécurisé et qui tient bien la route. Comme je suis seul utilisateur du serveur, je ne voyais pas trop l’intérêt de créer des comptes utilisateurs sur le serveur juste pour pouvoir bénéficier d’un serveur mail.

J’ai donc opté pour la solution suivante : un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et un serveur Courier (accès POP et IMAP) qui utilisent MySQL (utilisateurs et domaines virtuels) pour la redirection des messages des utilsateurs/domaines.

icon mail server1

Le tutoriel est certainement le plus long de la série, j’estime que cela prend à peu près 50 minutes à compléter (en 15 étapes!). Attention au niveau des copier/coller, une simple erreur peut vous faire perdre pas mal de temps !

Etape 1 : configurer le hostname

Le hostname est le nom du serveur en général. Mon domaine est skyminds.net donc mon serveur s’appelle mail.skyminds.net

Il est également important que ce nom soit présent dans la configuration bind du serveur.

Pour connaitre le nom de votre machine, tapez :

hostname -f

Pour le modifiez, il faut éditer /etc/hostname :

nano /etc/hostname

Remplacez ce qui s’y trouve avec le nom de votre serveur. J’y mets ‘mail.skyminds.net’.

Ensuite, éditez /etc/hosts:

nano /etc/hosts

On ne touche pas à la première ligne mais on ajoute l’adresse IP du serveur suivie de notre nom de machine :

127.0.0.1       localhost.localdomain localhost
xxx.xxx.xxx.xxx  mail.skyminds.net

Il ne vous reste plus qu’à rebooter le serveur pour que les modifications soient prises en compte :

/sbin/reboot

Vérifiez bien que le nouveau nom a bien changé :

hostname -f

J’obtiens bien :

mail.skyminds.net

Si vous obtenez une erreur du style “name or service not found”, vérifiez que les enregistrements DNS du serveur sont bien corrects.

Lire la suite