Au vu d’un précédent sondage, les lecteurs ont largement envie de plus de howto/documentation. Voici donc un tutoriel pour mettre en place une solution pour héberger ses courriels. Jusque‐là, c’est assez classique, mais on va aller un peu plus loin en ajoutant une solution pour lutter contre le pourriel (spam), qui apprend en fonction de ce que l’utilisateur configure. Cette solution vise une installation pour quelques utilisateurs maximum (on ne parle pas de LDAP, par exemple). Qui plus est, ils doivent être de confiance, car ils ont accès à certaines commandes qui peuvent poser des problèmes. Ils n’ont pas non plus de quota maximum.
L’installation et la configuration ont été testées sur Debian Wheezy, mais devraient fonctionner pour toute distribution.
Sommaire
Les paquets à installer sont : postfix, opendkim, dspam, dovecot-imapd, dovecot-lmtpd, dovecot-antispam et dovecot-sieve.
DNS
Premièrement, il faut configurer les enregistrements DNS du serveur. Le protocole SMTP a son propre type d’enregistrement DNS, le type MX
. L’enregistrement donne le nom du serveur et une priorité (il est donc possible d’avoir de la haute disponibilité simplement). Voici un exemple :
example.com. 10800 IN MX 0 serveur1.example.com.
↑ ↑ ↑ ↑
(1) (2) (3) (4)
- (1) est le domaine où l’on veut envoyer un courriel ;
- (2) est le délai, en secondes, pendant lequel l’information peut rester en cache ;
- (3) est la priorité, s’il n’y a qu’un seul serveur, ça n’a pas d’importance, s’il y en a plusieurs, cela permet de définir l’ordre dans lequel il faut les contacter ;
- (4) est le nom de la machine qu’il faut contacter.
Pour éviter de se faire prendre pour un spammeur, il est aussi intéressant de configurer un enregistrement SPF. Cela permet de définir quels serveurs sont autorisés à envoyer du courriel pour le domaine spécifié. Le plus simple est d’autoriser uniquement le serveur à envoyer des courriels :
example.com. 10800 IN SPF v=spf1 mx -all
Avec l’enregistrement précédent, on spécifie que seuls les serveurs enregistrés dans un MX pour example.com peuvent envoyer des courriels provenant de example.com. Il faudra donc toujours passer par le serveur pour envoyer des courriels.
NdM : autre exemple avec un champ TXT, plus couramment utilisé (cf. le résumé de S. Bortzmeyer sur la RFC 6686) :
linuxfr.org. 878 IN TXT "v=spf1 a mx ~all"
Postfix
Postfix est un MTA (Mail Transfer Agent), il se charge de transférer les courriels qu’il reçoit au bon destinataire qui peut être : soit le serveur en question, si le courriel lui est destiné, soit un autre serveur, si le courriel est destiné à une autre machine (parce que l’utilisateur local l’a envoyé, par exemple). Après l’installation des dépôts de la distribution, il faut adapter le fichier de configuration de Postfix (/etc/postfix/main.cf
) pour définir le nom d’hôte et les noms de domaines qui sont considérés comme locaux, en modifiant les lignes suivantes :
#On définit le nom d'hôte
myhostname = serveur.example.com
#On définit l'origine des courriels (ce qu'il faut ajouter après le @ pour les courriels sortants). Attention à remplir le fichier en conséquence
myorigin = /etc/mailname
#On définit les destinations pour lesquelles on accepte les courriels
mydestination = serveur1.example.com, example.com
Il peut être intéressant aussi d’augmenter la taille maximum des messages (2 Mio, par défaut) :
#Taille de message de 10 Mio maximum
message_size_limit = 10485760
Ensuite, il faut empêcher le serveur d’être un open mail relay, c’est‐à‐dire d’envoyer du courriel provenant de n’importe quelle source. Ceci afin d’éviter de relayer du pourriel. Il faut ajouter ou modifier les lignes suivantes (qui sont déjà la configuration par défaut d’un Postfix) :
#les adresses autorisées à envoyer des courriels. Ici seulement l'hôte local
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
#ensuite, on active l'authentification des utilisateurs
smtpd_sasl_auth_enable = yes
#on utilise dovecot pour authentifier les utilisateurs
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
#on note l'identifiant de l'utilisateur dans les messages
smtpd_sasl_authenticated_header = yes
#on définit les restrictions, c'est-à-dire les règles de refus ou d'acceptation d'un message, à l'étape RCPT TO, ici en autorisant tous les messages soumis depuis $mynetworks ou depuis un utilisateur précédemment identifié par SASL, en rejetant tous les autres messages à destination de noms de domaines non gérés ou d'utilisateurs inexistants dans les noms de domaines gérés, et en acceptant implicitement tout le reste.
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
Contrairement à ce que l’on voit parfois, le port 25 n’est pas dédié à soumettre les courriels à envoyer au serveur, il n’est utile que pour que les MTA se parlent entre eux. C’est le port 587 qui est utilisé pour que le client puisse envoyer ses courriels. Pour que Postfix écoute dessus, il faut décommenter (ou ajouter) la ligne suivante dans le fichier /etc/postfix/master.cf
:
submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
DKIM
DKIM est un service qui permet de signer tous les messages sortants par le serveur. Il n’identifie pas l’auteur du message mais bien le serveur. Cela permet d’être sûr que les messages envoyés par le serveur sont bien légitimes, et permet de refuser les messages qui ne le sont pas et, ainsi, de réduire le pourriel (sauf si votre serveur est un spammeur, mais c’est un autre problème).
Les clefs cryptographiques (default.txt
, pour la clef publique, et default.private
, pour la clef privée) sont générées avec la commande :
opendkim-genkey -d example.com
Il faut faire attention à se placer dans un dossier uniquement lisible par le démon dkim
, pour éviter que la clef privée soit lisible par tous. Par exemple, se mettre dans le dossier /etc/dkim/example.com
et faire un chown root:opendkim /etc/dkim/example.com/default.private && chmod 400 /etc/dkim/example.com/default.private
une fois que la clef est créée (le changement de groupe n’est pas très utile, mais je trouve que c’est plus cohérent).
La clef publique doit ensuite être publiée dans le DNS :
default._domainkey 10800 IN TXT "v=DKIM1; g=*; k=rsa; p=Le_contenu_du_fichier_default.txt"
On spécifie aussi la politique de signature (les courriels sont censés être signés) :
_adsp._domainkey.example.com 10800 IN TXT "dkim=all"
Et, là, les courriels non signés doivent être jetés :
_adsp._domainkey.example.com 10800 IN TXT "dkim=discardable"
Il faut ensuite modifier le fichier /etc/opendkim.conf
pour lui inclure les trois lignes suivantes :
Domain example.com
KeyFile /etc/dkim/example.com/default.private
Selector default
Il faut aussi ajouter la ligne suivante dans le fichier /etc/default/opendkim
. Elle permet d’indiquer au démon d’écouter sur une socket Unix. Comme le démon smtp
de Postfix tourne dans un chroot
(c’est la cinquième colonne de la ligne smtp dans le fichier /etc/postfix/master.cf
), il faut adapter le chemin au chroot
pour que le démon y ait accès :
SOCKET="local:/var/spool/postfix/var/run/opendkim/opendkim.sock" # chroot Postfix
Il faut ensuite créer le dossier et donner les droits à Postfix d’y lire et à OpenDKIM d’y écrire :
mdkir -p /var/spool/postfix/var/run/opendkim
chown root:opendkim /var/spool/postfix/var/run/opendkim
chmod 775 /var/spool/postfix/var/run/opendkim/
On peut ensuite redémarrer le service OpenDKIM.
Il faut maintenant indiquer à Postfix de faire signer les messages qu’il envoie. Pour cela on ajoute les lignes suivantes dans /etc/postfix/main.cf
:
## DKIM
smtpd_milters = unix:/var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock
Ensuite, on ajoute Postfix au groupe opendkim
pour qu’il puisse lire les données de la socket :
usermod -aG opendkim postfix
On peut enfin indiquer à Postfix qu’il peut transférer les courriels à destination de la machine qu’il reçoit via le protocole LMTP (Local Mail Transport Protocol) sur le port 2424, pour que Dspam puisse les analyser :
mailbox_transport = lmtp:inet:127.0.0.1:2424
Voilà, la configuration de Postfix est terminée. On peut redémarrer le service (si vous voulez éviter les surprises, il est quand même recommandé de redémarrer entre les différentes étapes pour voir si vous n’avez pas fait d’erreurs).
Vient la configuration de Dspam, pour lui dire d’écouter sur le port 2424.
Dspam
Premièrement, dans le fichier /etc/default/dspam
, il faut modifier les lignes suivantes :
START=yes
OPTIONS="--enable-daemon"
Ensuite, dans le fichier /etc/dspam/dspam.conf
, on ajoute :
#Listen a inet socket for incomming mail via lmtp
ServerHost 127.0.0.1
ServerPort 2424
ServerMode auto
ServerPass.client "password"
On configure aussi les informations pour que le client Dspam puisse se configurer (afin de pouvoir envoyer les informations d’apprentissage au serveur) :
#Client configuration
Trust mail
ClientHost 127.0.0.1
ClientPort 2424
ClientIdent "password@client"
Ensuite, on ajoute les utilisateurs de confiance. Avec la configuration donnée, Dovecot tourne sous l’utilisateur qui reçoit les courriels, il faut donc ajouter les utilisateurs qui recevront des courriels (ici, joe) :
Trust dspam-user
Trust xavier
On configure l’hôte et le port sur lesquels tourne le MDA :
#Send scanned mail via lmtp
DeliveryProto LMTP
DeliveryHost 127.0.0.1
DeliveryPort 24
DeliveryIdent localhost
On peut redémarrer dspam.
Dovecot
Dovecot est un MDA (Mail Delivery Agent) ; c’est‐à‐dire qu’il est en charge de récupérer les courriels et de les envoyer aux clients finaux.
La première chose à faire est d’activer l’authentification des utilisateurs pour que Postfix puisse l’utiliser comme on l’a spécifié. On modifie le fichier /etc/dovecot/conf.d/10-master.conf
comme suit :
service auth {
# auth_socket_path points to this userdb socket by default. It's typically
# used by dovecot-lda, doveadm, possibly imap process, etc. Users that have
# full permissions to this socket are able to get a list of all usernames and
# get the results of everyone's userdb lookups.
#
# The default 0666 mode allows anyone to connect to the socket, but the
# userdb lookups will succeed only if the userdb returns an "uid" field that
# matches the caller process's UID. Also if caller's uid or gid matches the
# socket's uid or gid the lookup succeeds. Anything else causes a failure.
#
# To give the caller full permissions to lookup all users, set the mode to
# something else than 0666 and Dovecot lets the kernel enforce the
# permissions (e.g. 0777 allows everyone full permissions).
unix_listener auth-userdb {
#mode = 0666
#user =
#group =
}
# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
mode = 0666
}
}
Après, comme Dovecot reçoit les courriels de Dspam avec une adresse de destination complète et qu’on utilise les utilisateurs du système, il est important de spécifier de n’utiliser que la partie avant le « @ », en modifiant le fichier /etc/dovecot/conf.d/10-auth.conf
:
auth_username_format = %Ln
On spécifie ensuite qu’on va utiliser le greffon antipourriel dans le fichier /etc/dovecot/conf.d/10-imap.conf
:
protocol imap {
mail_plugins = $mail_plugins antispam
}
Pour pouvoir recevoir les courriels via LMTP, il faut l’activer dans /etc/dovecot/conf.d/10-master.conf
:
service lmtp {
#unix_listener lmtp {
#mode = 0666
#}
inet_listener lmtp {
address = 127.0.0.1
port = 24
}
On va maintenant activer les filtres Sieve qui permettent d’appliquer des règles aux messages entrants directement sur le serveur.
Premièrement, on l’active dans /etc/dovecot/conf.d/20-lmtp.conf
:
protocol lmtp {
# Space separated list of plugins to load (default is global mail_plugins).
mail_plugins = $mail_plugins sieve
}
Ensuite, on configure le protocole managesieve (qui permet de gérer les filtres Sieve à partir du client de courriel) via le fichier /etc/dovecot/conf.d/20-managesieve.conf
:
service managesieve-login {
inet_listener sieve {
port = 4190
}
#inet_listener sieve_deprecated {
# port = 2000
#}
# Number of connections to handle before starting a new process. Typically
# the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0
# is faster. <doc/wiki/LoginProcess.txt>
service_count = 1
# Number of processes to always keep waiting for more connections.
process_min_avail = 0
}
Après, on configure le répertoire des filtres Sieves dans /etc/dovecot/90-sieve.conf
:
plugin {
# The path to the user's main active script. If ManageSieve is used, this the
# location of the symbolic link controlled by ManageSieve.
sieve = ~/.dovecot.sieve
# Directory for :personal include scripts for the include extension. This
# is also where the ManageSieve service stores the user's scripts.
sieve_dir = ~/sieve
}
On va maintenant parler du greffon antipourriel (antispam) de Dovecot, qui permet de gérer l’apprentissage du pourriel en fonction du déplacement du message dans les dossiers. Si vous déplacez le message de votre boîte de réception vers votre dossier Spam
, il va apprendre à l’antipourriel que c’est un pourriel. Si vous faites l’inverse, il va apprendre à l’antipourriel qu’il a fait une erreur.
Ce greffon fonctionne nativement avec Dspam, mais peut fonctionner avec n’importe quel client en appelant un exécutable et en envoyant le message via l’entrée standard.
La configuration se fait via /etc/dovecot/conf.d/90-plugin.conf
:
plugin {
antispam_backend = dspam
antispam_signature = X-DSPAM-Signature
antispam_signature_missing = error
#Noms des dossiers
antispam_trash = trash;Trash;Deleted Items; Deleted Messages
antispam_spam = SPAM;Spam
#Configuration du backend dspam
antispam_dspam_binary = /usr/bin/dspam
#Paramètre à donner à dspam quand le courriel est un spam
antispam_dspam_args = --user;%Lu@example.com;--source=error;--class=spam
#Paramètre quand le courriel est un ham
antispam_dspam_notspam = --user;%Lu@example.com;--source=error;--class=innocent
}
On remarquera qu’il faut spécifier le domaine d'origine des courriels, sinon il n’est pas passé de Dovecot à Dspam et cela pose des problèmes à ce dernier pour reconnaître les courriels à classer.
On peut redémarrer Dovecot.
Il faut enfin créer un filtre Sieve pour déplacer les spams dans le dossier approprié, on écrit donc un script dans le dossier sieve
de l'utilisateur, /home/joe/sieve/Spam.sieve
, par exemple :
if header :contains "X-DSPAM-Result" "Spam" {
fileinto "Spam";
}
Et on l’active en créant un lien :
ln -s /home/joe/sieve/Spam.sieve /home/joe/.dovecot.sieve
Ces deux dernières étapes peuvent être faites en utilisant un client de courriel qui gère le protocole Managesieve.
# supaÿr merci !
Posté par shoud (site web personnel) . Évalué à 3.
j'en avais justement besoin ce week end !
ça m'évitera bien des recherches
merci !
[^] # Re: supaÿr merci !
Posté par Nicephor . Évalué à 0.
Bon, et ben je vais virer zimbra et tout installer à la main avec un tuto comme ça, merci bien :)
[^] # Re: supaÿr merci !
Posté par ashgan . Évalué à 4.
dans la même veine, avec une base utilisateurs sous mysql plutôt qu'une base locale, j'aime beaucoup https://workaround.org/ispmail (en anglais)
c'est orienté vu l'utilisation de Debian, mais c'est fourni en explications et ça devrait être transposable assez facilement à d'autres distribs.
[^] # Re: supaÿr merci !
Posté par Loïc Blot (site web personnel) . Évalué à 4.
Sans vouloir faire ma propre pub, un lien avec une install sous FreeBSD, mais cette fois branchée sur un annuaire LDAP:
http://www.unix-experience.fr/2012/monter-son-serveur-mail-dovecotpostfixldapzfs-sous-freebsd/
Veepee & UNIX-Experience
[^] # Re: supaÿr merci !
Posté par rpnpif . Évalué à 1.
Je ne comprends pas bien l'intérêt de LDAP ici. Le carnet d'adresses ?
[^] # Re: supaÿr merci !
Posté par Julien L. . Évalué à 2.
La gestion des utilisateurs "virtual" ce qui n'est pas si mal déjà
[^] # Re: supaÿr merci !
Posté par Loïc Blot (site web personnel) . Évalué à 1.
Désolé du retard. C'est exactement ca. Tu n'as rien à faire sur ton dovecot, tu le branche sur le LDAP et immédiatement tous tes users peuvent utiliser IMAP(S) avec leur compte LDAP :)
Veepee & UNIX-Experience
# Open relay
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
C'est vrai, il faut éviter d'être un open relay, et pour ça il suffit… de ne rien faire. Dieu merci, les développeurs de Postfix ne sont pas complètement cons, et avec une configuration vide, n'utilisant donc que des valeurs par défaut, Postfix ne fait pas relais ouvert. Les mainteneurs du paquet Debian ne sont pas crétins non plus, et avec toutes les configurations proposées par le paquet, Postfix ne fait jamais relais ouvert.
Non. Il ne faut rien du tout, ces lignes apportent un raffinement, mais qui ne rend pas Postfix moins relais ouvert.
Je ne comprends rien au commentaire qui précède cette ligne, mais je comprends ce qu'elle fait : elle définit la liste des réseaux IP considérés comme locaux, donc autorisés à soumettre du courrier à destination de n'importe qui. Et elle la fixe d'ailleurs à sa valeur par défaut, autrement dit : cette ligne est parfaitement inutile.
La suite, c'est pour activer la prise en charge de l'identification SASL en SMTP.
Le commentaire est très, très confus. Cette ligne définit les restrictions, c'est à dire les règle de refus ou d'acceptation d'un message, à l'étape RCPT TO, ici en autorisant tous les messages soumis depuis $mynetworks ou depuis un utilisateur précédemment identifié par SASL, en rejetant tous les autres messages à destination de noms de domaines non gérés ou d'utilisateurs inexistants dans les noms de domaines gérés, et en acceptant implicitement tout le reste.
[^] # Re: Open relay
Posté par claudex . Évalué à 10.
Merci pour ces précision, mais c'est dommage de ne pas les avoir faites lorsque la dépêche était en rédaction.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Open relay
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Je suis les dépêches publiées, j'en rédige parfois, mais suivre ce qui est en rédaction, je n'ai pas encore réussi à m'y mettre.
[^] # Re: Open relay
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Open relay
Posté par Patrick Lamaizière (site web personnel) . Évalué à 6.
Ben non, dans la doc http://www.postfix.org/postconf.5.html#mynetworks il est précisé :
"By default, Postfix will forward mail from clients in authorized network blocks to any destination. Authorized networks are defined with the mynetworks configuration parameter. The default is to authorize all clients in the IP subnetworks that the local machine is attached to.
IMPORTANT: If your machine is connected to a wide area network then your default mynetworks setting may be too friendly."
Donc par défaut "mynetworks" comprends les sous-réseaux attachés à la machine, ce qui peut poser problème. Perso j'ai toujours un postfix en local qui me sert à envoyer les mails, mais je ne veux pas que les autres machines du réseau puissent l'utiliser pour relayer. Ama fixer mynetworks est une saine précaution.
(Bien lire la doc de postfix de toutes façons, un tutorial ça ne remplace pas la doc.)
les pixels au peuple !
[^] # Re: Open relay
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
En effet, avec une configuration vide, reposant sur les valeurs par défaut, Postfix fait relais ouvert pour le réseau local, ce qui convient tout à fait dans le cas d'un serveur d'un petit réseau, et ne convient pas du tout pour un dédié qui a des ordinateurs tout à fait étrangers à côté, mais n'est tout de même pas dramatique : ce n'est pas un relais ouvert pour tout Internet tout de même.
C'est là que la configuration par défaut de Debian est intéressante, parce qu'il me semble qu'elle fixe $mynetworks aux adresses locales uniquement.
# submission
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Plus. N'est plus dédié à cela : c'était le cas il y a longtemps mais cet usage est caduque, remplacé par l'utilisation du port submission en effet.
[^] # Re: submission
Posté par plic . Évalué à 5.
Menfin, Tanguy ?
Venant de toi, je suis déçu : caduc, palsambleu !
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: submission
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Merci, je n'avais pas fait attention, j'ajoute ça à ma liste de fautes à traquer dans mes textes.
# ADSP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
On spécifie aussi la politique de signature (les courriels non signés doivent être jetés)
Non. Ça indique que tous les messages sont censés être signés, sans préciser ce que le destinataire doit faire de ceux qui ne le sont pas. Pour indiquer qu'il doivent être jetés, c'est :
[^] # Re: ADSP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Et au passage, intéressez-vous aussi à DMARC, qui est à mon avis beaucoup plus utilisé qu'ADSP.
[^] # Re: ADSP
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé et complété, merci.
# petite question
Posté par Christophe B. (site web personnel) . Évalué à 5.
juste une petite question sur l'expression dans le DNS
est il possible d'avoir :
un domaine example.com qui reçoit ses mails avec serveur1.example.com
un sous domaine dom1.example.com qui reçoit ses mails avec mail.dom1.example.com
voir même un autre sous domaine qui reçoit ses mails avec mail.dom2.example.com
Chaque serveur de mail ne gérant que sa partie en émission comme en réception.
Sans que cela ne f….. la grouille :)
Sinon merci pour ce HOWTO, je ne connaissais pas DKIM, mais existe t il quelque chose qui permet l'authentification mutuelle.
Exemple : échange de mail bitoubi, comme dise les merciaux, mais avec reconnaissance de l'émetteur ET du récepteur ?
[^] # Re: petite question
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Oui, absolument. Le caractère hiérarchique du DNS n'a absolument aucune influence sur le courrier électronique, pour lequel chaque nom de domaine est unique et indépendant des autres.
Je ne comprends pas, peux-tu préciser, notamment avec des exemples de cas de refus et d'acceptation ?
[^] # Re: petite question
Posté par Christophe B. (site web personnel) . Évalué à 1.
C'est juste que je souhaite emettre et recevoir uniquement qu'avec des "serveurs" et "utilisateurs" reconnu
Comme de l'échange de fichier style CFT. Je n'accepte les messages que des serveurs/utilisateurs que je connais et vice et versa.
Cela existait au temps de transpac et des BAL (boites aux lettres)
Mais en fait en cherchant EDIFACT sur google et en fouillant je trouves des infos cela existe encore :)
[^] # Re: petite question
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Beurk. Heureusement que le courrier électronique s'est développé comme système ouvert. Mais bref, c'est faisable avec des trucs comme :
[^] # Re: petite question
Posté par Christophe B. (site web personnel) . Évalué à 2.
La liberté c'est aussi de pouvoir fermer sa porte quand on le veut :)
En gros ce qui m’intéresse c'est :
un serveur de mail ouvert :) => pour tout le monde
un autre serveur de mail restreint => client en compte, ma famille etc … (je sais pas encore je me pose juste la question)
J'accepte tout le monde chez moi, mais si tu te pointes sans prévenir c'est pas la même chose … :)
Ma boite mail principale, j'ai du la crée au temps ou internet, le mail, les newsgroups étaient quasi dénués de publicité. (le siècle précédent)
Donc naïvement je laissais mon adresse mail dans des newsgroups comme comp.os.unix ou fr.comp.os.unix ( #moulon rtfm pour ceux qui se souviennent )
depuis je dois recevoir entre 300 et 400 mails par jour dont seulement 5% m’intéresse, j'ai du ramener le volume à 200 mails / jours en virant tout ce
qui n'est pas dans un alphabet compréhensible par moi ( style les pubs coréennes et sud asiatiques ) après je tri mais malgré cela
il me reste encore beaucoup de pub et de cochonneries. dont certaines sont méritées …
[^] # Re: petite question
Posté par KiKouN . Évalué à 3.
# Clé publique
Posté par Benoît . Évalué à 2.
J'imagine que tu voulais dire "clé privée"; la clé publique peut, comme son nom l'indique, être lisible par tous sans que ça pose de problème.
[^] # Re: Clé publique
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Tuto sympa
Posté par AgentSteel (site web personnel) . Évalué à 5.
qui aurait largement sa place dans un wiki :)
pourquoi pas sur wiki.auto-hebergement.fr d'ailleurs?
(il y a déjà un tuto sur Postfix, mais légèrement différent)
# solution antispam
Posté par jeekajoo (site web personnel) . Évalué à 3. Dernière modification le 11 octobre 2013 à 20:12.
Cette news tombe plutôt bien car j'étais justement en train de m'installer mon serveur de mail sur mon dédié. J'en suis à la partie antispam.
Selon vous, il faut privilégier spamassassin, dspam ou bogofilter pour de l'auto-hébergement avec des ressources limitées.
J'ai lu que spamassassin était plus gourmand car écrit en perl contrairement aux 2 autres, écrits en C. Après j'aimerais des retours d'expériences sur l'efficacité et la maintenance nécessaire des différentes solutions.
Merci à l'auteur pour la news, et merci par avance à ceux qui me répondront.
[^] # Re: solution antispam
Posté par Ambroise . Évalué à 2.
Avant de te mettre à des solution de type spamassassin, essaies le graylisting. C’est pas trop mal comme solution…
[^] # Re: solution antispam
Posté par jeekajoo (site web personnel) . Évalué à 2.
mouai perso j'ai pas envie d'attendre pour recevoir un mail
[^] # Re: solution antispam
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Il y a des filtres de liste grise qui évitent l'attente en exemptant d'attente :
[^] # Re: solution antispam
Posté par MrLapinot (site web personnel) . Évalué à 4. Dernière modification le 12 octobre 2013 à 10:19.
Il y a aussi sa-exim, qui analyse le message avec spamassassin au moment de sa réception (avant de dire à l'émetteur qu'il a été accepté) et applique du greylisting seulement si le score est ambigu.
# Enregistrement SPF
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Pour SPF, l'enregistrement nommé SPF n'a quasiment jamais été utilisé. Comme noté dans le RFC 6686, qui faisait le bilan de SPF, le type d'enregistrement DNS recommandé est TXT.
http://www.bortzmeyer.org/6686.html
[^] # Re: Enregistrement SPF
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Ajouté, merci.
# Journal et auto-répondeurs
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 9.
Je me permets d'ajouter deux conseils à ce utile HOWTO : 1) au début, bien regarder le fichier journal (/var/log/mail.log par défaut sur une Debian) pour voir si tout se passe bien. Gérer un serveur sans regarder le journal, c'est être un chirurgien qui ne opère les yeux fermés. 2) tester son serveur avec des auto-répondeurs http://www.bortzmeyer.org/repondeurs-courrier-test.html
# maillon dspam
Posté par RD . Évalué à 5.
De la chaîne, Dspam est probablement l'élément plus sensible (segfault faciles).
J'ai toujours utilisé la méthode de boucle Postfix avec:
check_sender_access -> dspam.sock -> smtpd à nouveau, non filtré sur localhost
Mais en cas de plantage de dspam les emails restent secrètement dans la queue de postfix.
Je ne suis pas certain que la méthode basée sur dovecot soit moins risquée pour les emails, en cas de faillite de dspam.
À noter aussi, l'importance de saisir les ipv6 dans
mynetworks
car si celles-ci sont oubliées le jour où une ipv6est activée, on peut se retrouver dans l'un des rares cas dans lequel des emails sont droppés sans crier gare:
(le cas exposé y est peut-être moins sensible, mais dans le cas d'une réinjection dspam <-> postfix, indépendemment de la présence de AAAA, localhost s'avère être résolu différemment par la libc ce qui peut avoir des effets imprévisibles).
D'où possiblement
smtp_address_preference = ipv4
[^] # Re: maillon dspam
Posté par Naha (site web personnel) . Évalué à 1.
J'arrive un peu tard, mais j'approuve et j'ajoute qu'en plus d'être assez buggé, dspam n'est plus maintenu, à part par l'empaqueteur Debian et peut-être d'autres. Ledit empaqueteur Debian prévoit d'ailleurs d'abandonner le paquet dans un futur plus ou moins proche (après jessie, peut-être après jessie + 1). À mon avis, d'autres solutions sont donc à privilégier.
[^] # Re: maillon dspam
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
En même temps, SpamAssassin ne semble pas beaucoup plus vivace, il ne s’est rien passé depuis 2011, et j’ai l’impression qu’il fait de moins en moins bien le boulot… Tu proposes quoi à la place pour filtrer sur le contenu ?
[^] # Re: maillon dspam
Posté par Naha (site web personnel) . Évalué à 1.
Hum, il me semblait que SpamAssassin était plus actif, mais apparemment je me trompe. Je n'ai jamais essayé SpamAssassin (pour l'instant on tourne encore avec dspam) mais il me semblait qu'il avait aussi une plus grosse communauté d'utilisateurs et qu'il était moins buggé. Mais ce ne sont que des suppositions.
Cela dit, dspam est assez efficace quand il fonctionne.
# Deux trois choses
Posté par Joris Dedieu (site web personnel) . Évalué à 3. Dernière modification le 12 octobre 2013 à 13:48.
1 - reverse DNS
Le RFC 5321 précise qu'un serveur SMTP peut vérifier que le nom de domaine donné dans la commande EHLO correspond à l'adresse IP du client. Même si ce n'est pas un critère suffisant pour refuser les mails.
Dans la pratique cela signifie qu'une machine bien configurée dit :
Sans cela votre score comme spammer risque d'être incrémenté, voire vos mails refusés par certains fournisseurs d'antispam (postfix : smtpd_helo_restrictions).
2 - Envoyer doucement.
Beaucoup de fournisseurs (yahoo, orange, hotmail) n'aiment pas trop qu'on envoie des mails trop rapidement vers chez eux. Et ils ont souvent raison de le faire. Il est donc important, sans tomber dans le travers des
spameursrouteurs qui ont une politique différente par provider, d'ajuster les paramètres :default_destination_recipient_limit
default_destination_rate_delay
Afin que les emails soient envoyés doucement.
Surtout si on héberge des mailling-list.
3 - Si possible utilisez STARTTLS (voir par exemple http://www.bortzmeyer.org/postfix-tls.html)
4 - Ne jamais accepter un mail qu'on est pas sûr de pouvoir délivrer.
Dès qu'un mail est rentré dans vos spools, vous êtes susceptible de générer un bounce et donc un spam.
Le cas typique est un MX secondaires qui ne possède pas la liste des adresses valides. Il reçoit les mails et les forwarde sans plus de contrôle ou juste en contrôlant le domaine au MX principal. Ainsi, en envoyant des mails au MX secondaire pour une adresse qui n'existe pas sur votre domaine, je pourrais l'utiliser pour spamer l'adresse d'expéditeur.
[^] # Re: Deux trois choses
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6.
Non, le RFC 5321 ne parle pas du tout de cette vérification très contestée (ou d'une autre). Le seul qui la documente est le 7001 http://www.bortzmeyer.org/7001.html
[^] # Re: Deux trois choses
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
Il me semble pourtant que la section "4.1.4. Order of Commands" précise :
An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.
Mais peut-être fais-je un contre-sens ?
Quand au fait que cette vérification soit contestable, je n'en disconviens pas et ce n'est pas mon propos. Elle est appliqué parfois en violation totale du protocole par des fournisseurs d'antispam. C'est aussi la règle RDNS_NONE de spamassassin.
[^] # Re: Deux trois choses
Posté par gouttegd . Évalué à 3.
Ça ne correspond qu’aux deux premières lignes de l’exemple que tu donnes :
Mais ça ne correspond pas à ta troisième ligne (
dig -x $IP donne $HOSTNAME
), où tu fais une vérification supplémentaire (un « reverse DNS lookup ») pour savoir si l’IP du client a un enregistrement PTR correspondant au nom annoncé.[^] # Re: Deux trois choses
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 1.
Ah, exact, désolé, je m'avais trompé. Ceci dit, l'algorithme n'est pas tellement détaillé.
[^] # Re: Deux trois choses
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est à dire? (oui, des chiffres!)
[^] # Re: Deux trois choses
Posté par Ife . Évalué à 0.
J'ai personnellement jamais eu de problème pour envoyer une centaine de courriel en une seconde à un destinataire chez gmail. (J'envoyait mes emails depuis en linode, j'ai jamais essayé d'envoyer une grosse quantité depuis un kimsufi ou une dedibox)
En revanche, j'ai travaillé avec des clients qui savait pas installer des serveurs mails, ou ils avait installé un Microsoft Exchange avec la config par défaut. Et au delà de 2 emails par secondes, ça rejette. Et donc vu qu'ils ne savait pas comment configuré ça, je me suis retrouvé à configurer postfix pour qu'il réduise le taux de mail à la seconde.
Personnellement, je ne veux pas perdre un seul email, donc je ne fait pas de graylisting, pas vérification du EHLO, pas de limite d'email par seconde. J'utilise un catch-all, et je m'inscrit ou donne l'adresse email: nom-du-site-web@mon-domaine.com, par exemple: linuxfr@example.net . Et quand je reçois des spams sur cette addesse, je la supprime.
Mais on ne peux pas faire ça partout, et je comprends qu'on veuille limiter la quantité d'email reçu par seconde/minute.
Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »
[^] # Re: Deux trois choses
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ça, c'est mal. Utiliser plutôt : nom-du-site-web@example.com.
Voilà !
[^] # Re: Deux trois choses
Posté par 16aR . Évalué à 0.
Je ne comprends pas la différence.
En gros avoir un nom de domaine dédié pour gérer ces mails àlakon ?
(ex: monmail@mondomaine.com, et site-web-a-la-noix@mondeuxièmedomainepourlespam.com ?)
[^] # Re: Deux trois choses
Posté par gouttegd . Évalué à 3.
Rien à voir. ;)
Tanguy, engagé dans sa quête pour le respect du RFC 2606, fustigeait juste l’emploi de mon-domaine.com comme exemple de nom de domaine fictif, alors qu’il existe des noms de domaine spécialement réservés pour servir d’exemples dans les documentations.
[^] # Re: Deux trois choses
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Essaye la même chez Orange.
[^] # Re: Deux trois choses
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Bonne question. Ça dépend des providers. Orange par exemple ça semble être 3 mails par secondes avant de te faire greylister
[^] # Re: Deux trois choses
Posté par Christophe B. (site web personnel) . Évalué à 1. Dernière modification le 14 octobre 2013 à 16:57.
Chez online.net c'est 100/h par connexion au dela => blocage une heure
il y a aussi je crois une limite en nombre de connexion simultanée
Et ya aussi la limite de qq Mo pour les pièces jointes qui hérisse le poil de certains.
# Mouai
Posté par yann-kaelig . Évalué à -9.
C'est plutôt moyen intéressant ce tutoriel.
Je dirais même plus, c'est une énième copie de plus parmi celles disponibles sur le web.
Difficile de comprendre qui en est la cible, les connaisseurs auront déjà pris le temps de lire les documentations des logiciels en question, les débutants n'y comprendront rien sans avoir au préalable eu "le courage" de lire la doc officielle.
Rien de nouveau à l'horizon mise à part quelques analyses pertinentes dans les commentaires.
Cela pourrait être meilleur en construisant un plan de rédaction, en y ajoutant des illustrations sur le fonctionnement et l'interaction des logiciels, etc… pour au final comprendre qu'un blog n'est pas le support adéquate à cela.
pertinent ou inutile ? Ni l'un ni l'autre, je préfère donner une note sur 20 et ce sera 10/20 et je me trouve généreux en ce début de fin de semaine ensoleillée.
Qui sera prêt à se lancer dans un tutoriel complet pour Opensmtpd ?
[^] # Re: Mouai
Posté par Maclag . Évalué à 6.
Et bien c'est là que tu peux apprécier toute la puissance de la collaboration: tu peux apporter des compléments d'infos là où tu le juges nécessaire dans le présent tutoriel dont la version "stable" pourrait être dans un wiki.
Et pour le tutoriel sur opensmtpd, tu peux cliquer en haut sur "Journal" puis sur le bouton "Écrire un journal".
Note en passant que je ne suis ni débutant ni expert, et que je tombe précisément dans la catégorie des gens qui trouvent ça assez détaillé sans en faire trop. Peut-être que je ne suis pas un cas isolé sur ce site?
[^] # Re: Mouai
Posté par Xavier Teyssier (site web personnel) . Évalué à 6.
Qui sera prêt à se lancer dans un tutoriel complet pour Opensmtpd ?
Vas-y !
Défini la cible, construit un plan de rédaction, apporte des illustrations, etc.
C'est par là : https://linuxfr.org/redaction , bouton "Commencer une nouvelle dépêche".
L'avantage d'un espace collaboratif, c'est que ceux qui le souhaite pourront venir t'aider. Ça tombe bien pour toi qui lance un appel.
Et avec un peu de chance, ceux qui n'aiment pas ta manière de rédiger ta news participeront pour l'améliorer plutôt que de simplement venir dans les commentaires critiquer après coup.
# Autre tutoriel en anglais extrêmement complet
Posté par MightyDucks (site web personnel) . Évalué à 2.
http://flurdy.com/docs/postfix/index.html
Il m'a servi à monter plus d'un serveur mail !
Beaucoup de détails mais pas trop d'infos pour les dns il est vrai…
# Beaurk
Posté par tuxicoman (site web personnel) . Évalué à -10.
C'est tellement simple que j'ai envie de vomir en lisant ce tutoriel simplifié.
Il n'y aurait pas un système plus simple pour s'envoyer juste des messages asynchrones?
[^] # Re: Beaurk
Posté par Donk . Évalué à 7.
Il y a La Poste
[^] # Re: Beaurk
Posté par tuxicoman (site web personnel) . Évalué à -1.
A part le moinssage, c'est tout ce que vous avez pour mme michu qui a son Gmail?
[^] # Re: Beaurk
Posté par ariasuni . Évalué à 3.
Est-ce qu'on a dit que l'auto-hébergement c'était pour M. ou Mme Michu?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Beaurk
Posté par tuxicoman (site web personnel) . Évalué à -1.
Est ce que l'informatique est pour Mme Michu? Est ce que le mail est pour Mme Michu? Est que la vie privée numérique est pour Mme Michu?
L'autohébergement est une réponse technique qui satisfait tout ca? Mais l'implémentation de la réponse technique est elle adaptée à Mme Michu?
Pour moi non et je retourne bosser pour que ca le soit.
[^] # Re: Beaurk
Posté par ariasuni . Évalué à 6.
Non, mais c’est déjà une solution pour ceux qui ont les capacités de le faire (ce qui est déjà très bien), de plus ça permet aux apprentis administrateur système de se faire la main.
Par ailleurs, comment veux-tu rendre l’auto-hébergement à la portée de tout le monde si personne ne s’auto-héberge en premier lieu pour bien comprendre tous ce qu’il faut savoir et ensuite rendre ces solutions accessibles?
Bref, pas la peine de cracher sur le travail des autres, ça ne fera pas avancer le schmilblick.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Beaurk
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Yunohost ?
# Merci !
Posté par salelodenouye . Évalué à 1.
Merci je cherchais depuis plusieurs semaine à virer mon Zimbra.
Je suis un peu perdu niveau config de serveur mail, je trouve que c'est un peu le bazar quand on a que des rudiments.
Du coup ce tuto avec les commandes bien expliquée et tt et tt est le bienvenue !! =)
# Typos et details
Posté par burps_fr . Évalué à 2.
Il manque 2 packages dans la liste de ce qu'il faut installer :
apt-get install opendkim-tools dovecot-managesieved
Une petite typo :
**mkdir** -p /var/spool/postfix/var/run/opendkim
Et un fichier qui est légèrement différent :
/etc/dovecot/conf.d/10-imap.conf
-->/etc/dovecot/conf.d/***20***-imap.conf
Sinon, j'avais tenté ya quelques mois d'installer un serveur de mail, ça buggait, j'avais mis ça de coté. Puis en voyant ce tuto, je m'y suis remis. Ça a l'air de fonctionner, mais en fait, ça ne fait pas le café (i.e. pas toutes les fonctionnalité que je désirais…).
En revanche, grâce aux commentaires, j'ai trouvé des liens qui m'ont intéressé ici et là.
Ce que je désirais et qui me manquait ? le webmail, la possibilité de gérer les utilisateurs en BD, avec une GUI…
Merci aux contributeurs et aux commenteurs !!
[^] # Re: Typos et details
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Pour le webmail : apt-get install roundcube ?
# Port 24 ou 2424 ?
Posté par Nono (site web personnel) . Évalué à -1.
Seul endroit où est indiqué le port 24, n'est-ce pas le port 2424 ?
Étant derrière un nat, dois-je FWD également le port 24 vers ma VM MAIL?!
[^] # Re: Port 24 ou 2424 ?
Posté par claudex . Évalué à 4.
Non, on envoie les message à Dovecot qui écoute sur le 24.
Si Dspam tourne sur la même machine que Dovecot ou si les deux machines sont derrière le NAT, tu ne dois pas le faire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Port 24 ou 2424 ?
Posté par Nono (site web personnel) . Évalué à -1.
Après quelques test (j'ai testé les deux, histoire d'être sur), Il semblerait que les deux discutes bien …
Aurait-il un moyen d'activer le debug ?
Je vois bien mes mails arriver, être traité par l'antispam, attribué en non-spam, avoir un beau :
Mes mails n'arrivent jamais dans ma boite de réception :/
Peut-être sieve ? lmtp ? malgré tout dspam qui communique mal avec le maildir des utilisateurs ?
Je suis tout nue sans log et il m'avait semblé avoir tout activé !
[^] # Re: Port 24 ou 2424 ?
Posté par Nono (site web personnel) . Évalué à 1.
Bon, grâce à ton aide de tout à l'heure, tout fonctionne au poil maintenant, pour ceux qui aurait des soucis :
J'ai dû rajouter :
dans /etc/dspam/dspam.conf
et définir
dans /etc/dovecot/conf.d/15-lda.conf
[^] # Script Sieve
Posté par Nono (site web personnel) . Évalué à 1.
Et, je pense qu'il manque le "require" dans le script sieve :
sous peine de se retrouver avec un joli
# package
Posté par dacrovinunghi . Évalué à 0.
opendkim-genkey est dans le paquet opendkim-tools
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.