Construction pas à pas d’un serveur d’e-mail entrant basé sur Debian, Postfix et Spamassassin.

Dans cet article, je vous présente un serveur avec la fonctionnalité suivante: accepter les mails pour un domaine, filtrer les spams indésirables avec plusieurs mécanismes, et renvoyer les messages acceptés vers une autre adresse extérieure au serveur.

J’ai volontairement voulu garder un modèle simple. Il n’y a pas de serveur web, ni de base de données qui sont installés. Dans sa version initiale, il n’y a pas de certificat SSL, pas de TLS, pas de mail encrypté. Mise à jour 18 juin 2013: ajout de cette fonctionnalité. La modification est tout en bas de l’article.

Il n’y a donc pas de panneau de configuration à la génération clic-clic. Quand vous vous serez fait la main à la spartiate avec des fichiers de configuration, libre à vous de chercher des panneaux d’aministration pour vous faciliter la vie, ou d’investiguer sur l’utilisation de Postfix et Mysql pour utiliser une base de données à la place de certains fichiers de configuration.

Dans cette configuration minimum, je vous inclus un serveur IMAP pour héberger des boîtes aux lettres locales. Cependant, soyez prudent et conscient de votre responsabilité. Les besoins de sauvegarde (backup) ne sont pas les mêmes pour un serveur de stockage que pour un serveur de transit.

Le serveur devra être robuste vis-à-vis des attaques et du spam.

Dans le jargon anti-spam, on parle de faux négatifs et de faux positifs. Les faux négatifs sont les spams qui n’ont pas été détectés, et les faux positifs sont des mails authentiques qui sont indûment considérés comme spams.

L’objectif est d’avoir le moins possible de faux négatifs, et surtout zéro faux positifs. Entre les deux il y a une zone grise où le diagnostic est incertain.

Le contrôle anti-spam est fait dès qu’un mail se présente à l’entrée du serveur.

Pour moi il est impératif qu’un mail considéré comme spam soit rejeté en temps réel durant la transaction SMTP. A partir du moment où le serveur accepte un message et dit “ok, je l’accepte et je m’en charge” il a l’obligation de le remettre à son destinataire. Tandis qu’en laissant le message indésirable sur la carpette devant la porte d’entrée, c’est le serveur de l’expéditeur qui a la responsabilité d’envoyer un message d’erreur à qui de droit. S’il devait malheureusement s’agir d’un faux positif, au moins son expéditeur serait notifié.

Voici les mécanismes que j’utilise pour laisser les indésirables dehors:

• forcer les serveurs expéditeurs à un respect strict de la syntaxe du protocole SMTP à commencer par le HELO,
• consultation de listes noires (“blacklists”) pour valider la réputation de l’adresse IP du serveur de l’expéditeur,
  zen.spamhaus.org , cbl.abuseat.org : avec ces deux listes on a un filtre très efficace,
• limitation du nombre de connexions simultanées depuis une même adresse IP,
• limitation du nombre de connexions consécutives depuis une IP dans un court laps de temps. Ces deux mesures bloquent effectivement les “brute-force attacks” ou “dictionary attacks”,
• après la moindre erreur SMTP: ajout d’une temporisation à chaque réponse dans le dialogue SMTP pour ralentir les attaques,
• après plusieurs erreurs SMTP: interruption de la connexion,
• vérification que l’adresse de l’expéditeur comporte un @nomdedomaine qui existe,
• quelques contrôles optionnels sur le contenu des en-têtes et du corps du message,
• quand toutes ces conditions sont remplies, le message est transmis au logiciel SpamAssassin pour lui attribuer un “score”. Un score de zéro ou négatif désigne un message sain. Dès 3 ou 4 points on arrive dans la zone grise. Un message dont le score dépasse 8, 9 ou 10 points est assurément du spam.

Pour une information complète, voici les mécanismes que j’ai utilisés à un moment, mais que j’ai abandonnés complètement ou partiellement:

• contrôle du SPF (pour savoir ce qu’est SPF, voyez openspf.org et Wikipedia). Certains administrateurs de domaines incompétents mettent des règles de validations SPF qui provoquent des erreurs et empêchent effectivement la réception des mails. Et finalement, il s’avère que SPF ne bloque quasiment aucun mail frauduleux. Le gain est donc nul voire négatif.
  J’ai abandonné le rejet sur base du SPF.
  SpamAssassin consulte aussi SPF pour attribuer quelques bons ou mauvais points au message entrant, et le score total SA sera déterminant.
• Greylisting (voir Wikipedia). En bref, pour un nouveau serveur/correspondant qui m’expédie un message, le serveur simulera un souci temporaire. Le serveur de l’expéditeur devra donc réessayer un peu plus tard. Très intéressant pour les adresses génériques du genre contact@example.com. Par contre, c’est parfaitement casse-pieds pour les adresses d’individus comme vous et moi. Je prends un exemple: à 19h30 je commande on-line un ticket de cinéma pour la séance de 21 heures. Le ticket électronique est bloqué et n’arrive pas à cause du greylisting. Il me parviendra plus tard, avec un retard dont la durée ne dépend pas de moi mais de la bonne volonté du serveur d’envoi de mail du cinéma. Dans les meilleurs cas 5 minutes, mais parfois plusieurs heures…
• Je n’ai pas implémenté d’antivirus. Dans 99% des cas le serveur auquel je retransmets les messages s’en chargera. Un antivirus engendre une charge importante ce qui peut être gênant dans un tout petit serveur où le CPU et la mémoire sont comptés.
• Certains serveurs mail se vantent de pouvoir vérifier si l’adresse de l’expéditeur existe bel et bien. Ce mécanisme est égoïste et à éviter. Comment cela se passe-t-il ? Mon serveur “example.com” est en train de recevoir un message de a@truc.machin  à destination de moi@example.com . L’objectif est de vérifier si l’adresse a@truc.machin existe. Pour cela on va demander au serveur du domaine ‘truc.machin’ si l’adresse ‘a’ existe. Tout en maintenant ouverte la réception du message, mon serveur émet une nouvelle connexion vers ce serveur et annonce qu’il a un e-mail à remettre à a@truc.machin . Soit la commande est refusée (exemple a@truc.machin : user unknown), soit elle est acceptée. Dans les deux cas mon serveur interrompt abruptement la conversation avec ce serveur truc.machin sans envoyer le moindre contenu de message, et puis continue la conversation avec le premier. Selon la réponse reçue du deuxième, l’adresse d’expéditeur a@truc.machin présentée par le premier sera validée ou rejetée.
  Ah oui, j’avais dit “égoïste”. Si le serveur truc.machin fait la même chose que moi, on est dans une situation de blocage. Marrant, non ?
• On pourrait aussi faire un contrôle sur l’adresse IP du serveur qui se connecte sur le mien, et vérifier que le hostname (résolution DNS inverse) existe et correspond aussi bien que dans l’autre sens.
  Exemple: je reçois une connexion de 123.45.67.89 . DNS me dit qu’à cette adresse IP correspond le nom mailhost.domaine.com . Si l’adresse IP de mailhost.domaine.com est 123.45.67.89 c’est excellent. Et si la machine se présente avec HELO mailhost.domaine.com c’est vraiment parfait.
  Si on devait rejeter tous les mails qui ne satisfont pas à cette condition, bonjour les dégâts.
• Et puis il y a les black lists qui ont causé des problèmes :

1. dnsbl.sorbs.net : c’est absolument à éviter ! c’est la plus mauvaise black list qui existe ! Son gestionnaire y ajoute n’importe qui à la première demande (y compris dans l’intention de nuire) et puis fait du racket pour enlever les adresses qui s’y trouvent.
2. dnsbl.dronebl.org
3. ubl.unsubscore.com : essayé, mais pas adopté
4. dnsbl-1.uceprotect.net (et dnsbl-2 et dnsbl-3) : beaucoup trop de faux positifs
5. bl.spamcop.net : très bonne liste avec une excellente réactivité, quelques faux positifs néanmoins

Passons enfin à la réalisation. J’estime que vous savez utiliser un éditeur de textes, ‘vi’ ou ‘nano’.

On choisit un serveur. Pour un serveur privé avec moins de quelques milliers de messages par jour, un serveur virtuel avec 256 MB d’entrée de gamme suffit.

Je commande un vKS “small” chez OVH, 512 MB RAM, 6 euros TVAC par mois. Moins de 10 minutes après le paiement, la machine est prête.

Bonjour,
Votre VPS vient d'être installé sous le système d'exploitation Debian 6.0 (Squeeze) (en version 64 bits)
PARAMETRES D'ACCES:
L'adresse IP du vKS est : 37.59.124.xx
Le nom du vKS est : vks1069x.ip-37-59-124.eu (jusqu'à 48h peuvent être nécessaires pour que ce nom soit actif)
Le compte administrateur suivant a été configuré sur le vKS :
Nom d'utilisateur : root
Mot de passe : Vousyavezcru,hein?

La machine est préinstallée en Debian 6. Depuis le 20 juin 2012, OVH fournit les vKS avec une sélection de paquets qui n’est plus la même que précédemment. Je vous ferai peut-être enlever des paquets qui ne sont pas installés. Ce n’est pas grave.

On va se connecter dessus, au moyen de PuTTY ou ssh.

Debian 5 arrivait avec exim préinstallé. Depuis Debian 6, sendmail est préinstallé. On n’a besoin ni de l’un ni de l’autre. Dans le cas de la machine OVH, le ménage a été fait juste avant la livraison et il n’y a ni exim, ni sendmail. (Exim, Sendmail, Qmail et Postfix sont des programmes qui servent à la même chose: traiter les mails)

Changer le mot de passe:

passwd

On va donc retirer les paquets qui ne nous intéressent pas, pour plus de sécurité.

apt-get remove samba samba-common sendmail sendmail-base sendmail-bin sendmail-cf sendmail-doc exim smartmontools

La suppression de smartmontools est recommandée uniquement sur les serveurs virtuels.

Puis une mise à jour s’impose.

apt-get update
apt-get upgrade

dpkg-reconfigure locales:
[*] en_US.UTF-8 UTF-8
dpkg-reconfigure tzdata:
Europe > Brussels

Changer le hostname (editer /etc/hostname et /etc/hosts)
par exemple mail.example.com
Dans /etc/hostname vous mettez juste le nom court (mail)
Dans /etc/hosts vous mettez le nom complet (mail.example.com) puis le nom court (mail).

C’est le moment d’aller configurer dans le DNS du domaine example.com la machine mail.example.com avec son adresse IP.
Chez OVH: dans le managerv3, Hébergement > DNS > Zone DNS > A > Destination personnalisée

C’est aussi le moment d’aller chez votre hébergeur afin qu’il configure le reverse dans le DNS, c’est à dire qu’à l’adresse IP du serveur, ça retourne l’information mail.example.com .
Chez OVH: dans le managerv5 > vKimsufi > Advanced Settings > Reverse DNS

Je propose de rebooter pour confirmer toutes ces mises à jour.

shutdown -r now

On va installer toute une série de paquets en commençant par Postfix

apt-get install postfix
-> this is an "Internet Site"
-> hostname mail.example.com (surtout pas example.com !)
apt-get install postfix-pcre
apt-get install postgrey
apt-get install courier-imap
-> (do not create directories)
apt-get install gamin
apt-get install spamassassin spampd
apt-get install libdate-calc-perl
apt-get install mailutils mpack sysstat logwatch
apt-get install ntpdate bind9 dnsutils

On configure postgrey (dans le fichier /etc/default/postgrey) . Mettre toutes les lignes actives en commentaire et ajouter ceci:

POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=65 --max-age=40 --retry-window=5h --auto-whitelist-clients=3"
POSTGREY_TEXT="Unable to accept the message now. Please retry later."

Comme je l’avais indiqué dans l’introduction, le greylisting n’est pas souhaitable pour toutes vos adresses. Vous avez deux fichiers pour spécifier les exceptions (qui ne doivent pas être soumises au greylisting).

Le premier (/etc/postgrey/whitelist_clients) contient des noms de serveurs qu’il ne faut pas greylister.

yahoo.com
google.com
scarlet.be
hotmail.com
yahoo.co.uk
ebay.com
europa.eu
paypal.com
mail-out.ovh.net
mxb.ovh.net
cert.org
bigfoot.com
brutele.be
/^.*smtp.*\.coditel.net$/
tech.numericable.fr

Le second (/etc/postgrey/whitelist_recipients) contient des adresses de destinataires qu’il ne faut pas greylister.

# exemple 1: ne pas greylister cette adresse
frederic@example.com
# exemple 2: ne pas greylister ce domaine
@example1.com

Après édition de ces fichiers, redémarrer Postgrey:

service postgrey restart

On configure le résolveur DNS (dans le fichier /etc/resolv.conf). Ajouter la ligne suivante en haut du fichier:

nameserver 127.0.0.1

A ce stade la machine est déjà capable d’envoyer des mails.

root@mail:~# mail fredericXdemeesXnet
Cc:
Subject: test d'envoi
Test
^D

Le mail doit parvenir au destinataire.

On peut aussi vérifier le logfile: ‘less /var/log/mail.log’ . Taper majuscule G pour aller à la fin. Taper q pour quitter.

On va mettre des aliases. Ceci se fait en éditant le fichier /etc/aliases . Ajoutez quelques lignes à la fin:

root: frederic
frederic: frederic.example@gmail.com

Le fichier /etc/aliases doit être indexé. Chaque fois qu’on l’a édité, il faut taper: newaliases

On va maintenant configurer Postfix. Tous les fichiers de Postfix se trouvent dans /etc/postfix . Les deux fichiers principaux sont master.cf et main.cf . En-dehors de ce répertoire, il y a aussi le fichier /etc/aliases . Après avoir fait des changements, il faut informer Postfix avec la commande ‘postfix reload’.

/etc/postfix/master.cf: Mettre la ligne suivante en commentaire en insérant #

smtp      inet  n       -       -       -       -       smtpd

et la remplacer par

# lines below: http://wiki.apache.org/spamassassin/IntegratePostfixViaSpampd
#
# Before-filter SMTP server. Receive mail from the network and
# pass it to the content filter on localhost port 10025.
#
smtp      inet  n       -       -       -       10       smtpd
        -o smtpd_proxy_filter=127.0.0.1:10025
        -o smtpd_client_connection_count_limit=2
#
# After-filter SMTP server. Receive mail from the content filter
# on localhost port 10026.
#
127.0.0.1:10026 inet n  -       n       -        -      smtpd
        -o smtpd_authorized_xforward_hosts=127.0.0.0/8
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o smtpd_data_restrictions=
        -o mynetworks=127.0.0.0/8
        -o receive_override_options=no_unknown_recipient_checks
#

Ces changements ordonnent de faire passer le flux de mail entrant via SpamAssassin. La communcation entre Postfix et SA se fait via les ports TCP 10025 et 10026.

Vous pouvez aussi ajouter une ligne comme celle-ci:

1234      inet  n       -       -       -       10       smtpd

Je vous expliquerai plus loin à quoi cette ligne pourra servir, et ce que désigne le 1234 que vous pourrez modifier.

Enregistrez le fichier.

On va apporter beaucoup de modifications au fichier main.cf . Plutôt que d’indiquer quelles lignes doivent être remplacées par quoi, je décris les lignes que j’ajoute. Si elles existent déjà ça signifie que je les remplace. Faites preuve de perspicacité.

# for debugging, remove the comment
#soft_bounce = yes

# Uncomment the next line to generate "delayed mail" warnings
delay_warning_time = 2h
bounce_queue_lifetime = 1d
maximal_queue_lifetime = 1d

#Support for Maildir
home_mailbox = Maildir/

myhostname = mail.example.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.example.com, example.com
virtual_alias_domains = virtual1.com, virtual2.com
virtual_alias_maps = hash:/etc/postfix/virtual
relayhost =
mynetworks = 127.0.0.0/8,   87.98.173.257
#  
#
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
queue_run_delay = 180
minimal_backoff_time = 180
policy_time_limit = 3600
smtpd_error_sleep_time = 5s
smtpd_soft_error_limit = 1
error_count = 50
smtpd_hard_error_limit = 3
message_size_limit = 40960000
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_client_connection_count_limit = 5
smtpd_client_connection_rate_limit = 5
unknown_address_reject_code = 550
unknown_client_reject_code = 550
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
smtpd_client_restrictions =
   cidr:/etc/postfix/client.cidr
smtpd_sender_restrictions =
   check_sender_access hash:/etc/postfix/sender_access,
   reject_non_fqdn_sender,
   reject_unknown_sender_domain
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   check_sender_access hash:/etc/postfix/relay_access,
   check_recipient_access hash:/etc/postfix/white_addresses,
   reject_invalid_helo_hostname,
   reject_non_fqdn_helo_hostname,
#   reject_unknown_reverse_client_hostname,
   reject_unauth_destination,
   reject_unauth_pipelining,
   reject_unlisted_recipient,
#   reject_rbl_client bl.spamcop.net
#   reject_rbl_client dnsbl.dronebl.org
#   reject_rbl_client dnsbl.sorbs.net
#   reject_rbl_client ubl.unsubscore.com
   reject_rbl_client cbl.abuseat.org
   reject_rbl_client zen.spamhaus.org
#   reject_rbl_client dnsbl-1.uceprotect.net
#   reject_rbl_client dnsbl-2.uceprotect.net
#   reject_rbl_client dnsbl-3.uceprotect.net
#   check_sender_access dbm:/etc/postfix/check_backscatterer,
#   reject_unknown_client_hostname
   check_policy_service inet:127.0.0.1:60000
smtpd_data_restrictions = reject_unauth_pipelining
header_checks = pcre:/etc/postfix/header_checks
body_checks = pcre:/etc/postfix/body_checks

Quelques explications s’imposent.

Soft_bounce permet, pendant une période de tests, de renvoyer systématiquement des erreurs non-fatales ‘4xx’ à la place des erreurs fatales ‘5xx’ durant la transaction SMTP. Ceci ordonne à l’expéditeur de venir représenter le même e-mail plus tard, au lieu de le renvoyer à son expéditeur.

delay_warning_time et les 2 lignes qui suivent: si un message reste en transit 2 heures sans pouvoir être transmis, l’expéditeur est alerté ; après 24 heures il est retourné à son expéditeur. Dans les standards des années ’70 et ’80 on recommandait 5 jours. Les réseaux étaient beaucoup moins robustes et il y avait beaucoup plus de connexions dial-up à ce moment. C’est pourquoi je considère que 1 jour est bien suffisant.

Maildir: ne sera utile que si le serveur héberge des boîtes aux lettres locales.

TLS et SSL: dans ce prototype ce n’est pas implémenté.

mydestination: cette ligne est très importante. Elle désigne les domaines pour lesquels une adresse est acceptée en entrée si elle figure dans /etc/aliases. Si vous avez deux domaines example.com et example.be qui sont parfaitement synonymes, vous pouvez indiquer les deux.

virtual_alias_domains: si vous souhaitez héberger des domaines additionnels, vous énumérez ici la liste de ces domaines additionnels.

relayhost: en laissant cette ligne vide, vous indiquez que votre serveur va livrer les mails en direct sans faire tout transiter par une machine SMTP tierce.

mynetworks: cette ligne importante désigne les adresses IP “amies” qui ont droit d’utiliser votre serveur sans aucune authentification. Attention j’ai mis une adresse IP invalide pour vous forcer à lire le présent manuel. 257 n’est pas acceptable dans une adresse IP.

recipient_delimiter: le signe + indiqué ici permet de créer des nouvelles adresses au vol. L’adresse user+nimportequoi@example.com est équivalente à user@example.com .

smtpd_error_sleep_time indique le nombre de secondes que postfix va ajouter comme délai pour répondre à chaque commande SMTP, dès que smtpd_soft_error_limit aura été atteint.

smtpd_hard_error_limit ordonne de couper la communication après autant d’erreurs dans le dialogue SMTP. Toutes les erreurs sont comptabilisées: fautes de syntaxe, utilisateur inconnu, etc.

smtpd_client_connection_count_limit et smtpd_client_connection_rate_limit indiquent le nombre de connexions simultantées et consécutives que Postfix va accepter depuis une même IP. Avec la directive précédente, ceci limite efficacement les brute-force attacks et dictionary attacks.

smtpd_client_restrictions : contrôles sur base du client (adresse IP du serveur qu parle avec moi)
cidr:/etc/postfix/client.cidr : permet de blacklister une adresse IP ou une plage d’adresses

smtpd_sender_restrictions : contrôles sur l’adresse de l’expéditeur
Le fichier sender_access permet d’interdire certaines adresses e-mail d’expéditeur
les deux lignes suivantes vont interdire un expéditeur dont l’adresse e-mail n’est pas conforme ou contient un nom de domaine inexistant.

smtpd_recipient_restrictions : contrôles sur l’adresse du destinataire
Contrôles sur le HELO. Ceci élimine une grande quantité de spam avec très peu d’efforts.
reject_unauth_destination, reject_unlisted_recipient: très important, ne supprimez pas ces phrases ! Sinon votre serveur devient un “open-relay”.

Ensuite viennent toutes les black lists. J’utilise abuseat et zen.spamhaus. Ca donne un excellent résultat.

Les header_checks et body_checks permettent d’accepter ou refuser un mail sur base du contenu (pattern matching). Ca peut être utile pour bloquer une campagne de spam qui contient un mot précis comme le nom d’un site web.

On va maintenant créer les fichiers annexes

client.cidr

202.138.126.0/24        450 I will not accept your message. Too many scams from your network.

sender_access

ebay@message.com 550 This sender is not authorized to send mail.
service@security.com 550 This sender is not authorized to send mail.

relay_access

# insert sender e-mail addresses that are always authorized to relay. This is a dangerous feature !
# otherwise leave this file empty

white_addresses

# laissez ce fichier vide. Vous pouvez insérer des adresses qui ne seront pas soumises à des contrôles additionnels. Vous pouvez aussi insérer des adresses de destinataires qui seront rejetées avec un message d'erreur de votre choix
# exemple: jean.dupont@example.com 553 5.7.1 Erreur, Jean est parti le 31 decembre, veuillez contacter son secretariat.

header_checks: ce sont des contrôles sur la partie en-tête SMTP du message. La première ligne provoque le rejet de messages qui contiennent ce List-Id. La seconde ligne fait partie de la stratégie SpamAssassin. Elle provoque le refus de messages qui atteignent un score de 8 ou plus. Spamassassin met une en-tête avec un nombre d’étoiles correspondant au score, il suffit de faire un pattern matching.

/^List-Id: .wb_bwadxxx.info/ REJECT User unknown.
/X-Spam-Level: \*{8,}/ REJECT Email rejected. Looks like spam. Please visit http://...... for contact address and more information.

body_checks: ce sont des contrôles sur le corps du message

/WWW\.LOUSNE\.COM/ REJECT My life is OK. Bye.

Enfin on crée un fichier ‘virtual’ qui contient les adresses de redirection pour les domaines virtuels

postmaster@example1.com frederic@example.com
info@example1.com example.1.2.3.4@gmail.com

Postfix utilise tous les fichiers suivants au format Berkeley DB pour faire un accès indexé, il faut donc créer ces fichiers au format DB.

postmap virtual
postmap sender_access
postmap relay_access
postmap white_addresses

On retiendra que chaque fois qu’on édite un de ces quatre fichiers, il faut envoyer la commande postmap correspondante.

Ensuite à chaque changement de n’importe quel fichier de Postfix, il faut taper: postfix reload.

On quitte maintenant le répertoire /etc/postfix

Configuraton de spamassassin (/etc/spamassassin/local.cf):

use_bayes 0
bayes_auto_learn 0
rewrite_header Subject \#\#\# SPAM _SCORE_ \#\#\#
required_score 3.0
report_safe 0
# Enable or disable network checks
skip_rbl_checks 0
##use_razor2 0
##use_dcc 0
##use_pyzor 0
#
score MISSING_MID 2.0 # instead of 0.001
score MISSING_DATE 2.0 # instead of 0.001
header SEXPILLS_IN_FROM From =~ /Sex.pills/i
score SEXPILLS_IN_FROM 4.9
# whitelist everyone at awex.be
whitelist_from  *@awex.be
blacklist_from a_stupid_spammer@vsnl.net

On va relancer le process spampd (‘pd’ pour ‘Policy Daemon’): service spampd restart
ou même rebooter le serveur pour être certain d’être dans un état connu.

Voilà. Si je n’ai rien oublié on doit avoir un serveur qui tourne.

Il nous reste à mettre deux cerises sur le gâteau.

La première option est d’accepter du mail entrant pour le relayer.

Vous pouvez de cette manière envoyer tous vos mails sortants depuis votre PC ou votre smartphone, et ne pas utiliser le SMTP de votre fournisseur Internet. Pratique quand on est nomade.

Vous pouvez aussi utiliser votre serveur dédié pour envoyer les mails à partir de vos sites qui sont hébergés sur un hébergement mutualisé.

Vous aurez besoin de 4 paramètres: le nom de votre serveur dédié, un login, un password et un numéro de port. Plus haut, je vous ai configuré le port n° 1234 dans master.cf. On va créer un utilisateur ‘envoi’ qui ne servira qu’à envoyer les messages:

adduser envoi

Vous choisissez un mot de passe, vous répondez aux questions, et le tour est joué.

Il faut faire quelques ajouts à la configuration.

apt-get install sasl2-bin

Ensuite il faut éditer /etc/default/saslauthd .
Ajouter ou remplacer les lignes suivantes:

START=yes
MECHANISMS="shadow"
THREADS=2
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Arrêter le service saslauthd:

service saslauthd stop

puis adapter sasl à postfix:

rm -r /var/run/saslauthd
ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd
chown root:sasl /var/run/saslauthd

service saslauthd start

puis un petit test:

testsaslauthd -u envoi -p password

Cette commande doit renvoyer le status Success uniquement si le login/password sont corrects.

Maintenant que sasl est testé, il reste à indiquer à Postfix d’utiliser sasl.
Créer un ficher /etc/postfix/sasl/smtpd.conf qui contient ceci:

pwcheck_method: saslauthd
saslauthd_version: 2
mech_list: PLAIN LOGIN
log_level: 5

et bien sûr postfix reload.

Voilà. Votre serveur est maintenant capable de relayer des mails moyennant authentification.

La deuxième cerise sur le gâteau maintenant. On va créer une boîte aux lettres locale. J’ai décidé de n’implémenter que le protocole IMAP (ne me demandez pas donc pas pourquoi POP3 ne fonctionne pas).

Volontairement je vais vous créer une boîte qui ne correspond pas à l’adresse e-mail correspondante. Ceci obligera à ajouter une ligne dans /etc/aliases.

On va créer un compte pour cet utilisateur.

adduser user1

Son “home directory” sera /home/user1 . On voudrait que ses mails soient stockés dans /home/user1/Maildir/ au format maildir et non au format mbox. Sous l’identité ‘user1’, nous allons préparer l’environnement.

su - user1
echo /home/user1/Maildir/ > .forward
logout

puis on va envoyer un mail à cet utilisateur (cette opération va créer des sous-répertoires sous /home/user1/Maildir/):

echo test | mail user1

Au format Maildir, chaque message est stocké dans un fichier individuel.

Il reste à ajouter une ligne dans /etc/aliases:

comptable: user1

ensuite, taper: newaliases

Ceci a pour effet de configurer l’adresse comptable@example.com vers user1. (L’adresse user1@example.com est aussi valable)

L’utilisateur qui a une boîte IMAP peut utiliser le même login/password pour son mail sortant en SMTP.

Mise à jour du 18 juin 2013: ajout du support SSL/TLS pour encrypter tous les mails entrants et sortants, si le serveur d’en face le supporte aussi.

Ceci se fait en 2 étapes: création des clés, ensuite configuration de Postfix.

cd /etc/postfix
mkdir tls
cd tls
openssl genrsa -rand ~/.bash_history -out smtpd.key 2048
openssl req -new -key smtpd.key -out smtpd.csr
openssl x509 -req -days 3650 -in smtpd.csr -signkey smtpd.key -out smtpd.crt
openssl rsa -in smtpd.key -out smtpd.key.plain
mv smtpd.key.plain smtpd.key
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

Au moyen des commandes ci-dessus vous allez créer un certificat valable 10 ans.
La référence au fichier ~/.bash_history sert à alimenter le générateur de nombres aléatoires avec une séquence difficilement prévisible.
A deux reprises vous devrez compléter votre pays, région, votre nom. Veillez à ce que le “common name” corresponde exactement au hostname de votre serveur mail.

Ensuite vous devrez éditer le fichier main.cf dans le répertoire /etc/postfix.

Mettez toutes ces lignes en commentaire

# TLS parameters
##smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
##smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
##smtpd_use_tls=yes
##smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
##smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

et insérez juste en-dessous:

smtpd_use_tls=yes
smtpd_tls_security = may
smtpd_tls_key_file = /etc/postfix/tls/smtpd.key
smtpd_tls_cert_file = /etc/postfix/tls/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/tls/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtp_tls_security_level = may
smtp_tls_loglevel = 1

et ensuite postfix stop ; postfix start

Merci aux bloggeurs qui m’ont conseillé, car la doc Postfix est un peu ardue à ce sujet.