Héberger son courriel

Posté par  . Édité par Davy Defaud, Benoît Sibaud, ZeroHeure, NeoX, palm123, Anonyme, Benoît, Petit_Scarabee, Nicolas Casanova, titinux et bastien. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
87
11
oct.
2013
Technologie

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  (site web personnel) . Évalué à 3.

    j'en avais justement besoin ce week end !
    ça m'évitera bien des recherches

    merci !

  • # Open relay

    Posté par  (site web personnel) . Évalué à 10.

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

    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.

    Il faut ajouter ou modifier les lignes suivantes :

    Non. Il ne faut rien du tout, ces lignes apportent un raffinement, mais qui ne rend pas Postfix moins relais ouvert.

    #on autorise n'importe qui à envoyer des email depuis les adresses suivantes, ici seulement l'hôte local
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

    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.

    #on définit les utilisateur authentifiés, c'est-à-dire ceux qui viennent de my_networks et ceux qui sont authenfiés par un nom d'utilisateur et un mot de passe.
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination

    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  . É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  (site web personnel) . Évalué à 3.

      Corrigé, merci.

    • [^] # Re: Open relay

      Posté par  (site web personnel) . Évalué à 6.

      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.

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

        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  (site web personnel) . Évalué à 10.

    Contrairement à ce qu'on voit parfois, le port 25 n'est pas dédié à soumettre les courriels à envoyer au serveur

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

  • # ADSP

    Posté par  (site web personnel) . Évalué à 6.

    On spécifie aussi la politique de signature (les courriels non signés doivent être jetés)

    _adsp._domainkey.example.com 10800 IN TXT  "dkim=all"

    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 :

    _adsp._domainkey.example.com 10800 IN TXT  "dkim=discardable"

  • # petite question

    Posté par  (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 ?

    <vendredi>
Chaque fois que je vois un howto comme celui ci cela donne envie de gérer un serveur de mail.
Mais étant petit, j'avais vu un sendmail.cf et depuis j'ai peur ... des serveurs de mails :)
</vendredi>

    • [^] # Re: petite question

      Posté par  (site web personnel) . Évalué à 4.

      Chaque serveur de mail ne gérant que sa partie en émission comme en réception.
      Sans que cela ne f….. la grouille :)

      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.

      Exemple : échange de mail bitoubi, comme dise les merciaux, mais avec reconnaissance de l'émetteur ET du récepteur ?

      Je ne comprends pas, peux-tu préciser, notamment avec des exemples de cas de refus et d'acceptation ?

      • [^] # Re: petite question

        Posté par  (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  (site web personnel) . Évalué à 3.

          C'est juste que je souhaite emettre et recevoir uniquement qu'avec des "serveurs" et "utilisateurs" reconnu

          Beurk. Heureusement que le courrier électronique s'est développé comme système ouvert. Mais bref, c'est faisable avec des trucs comme :

          smtpd_client_restrictions = check_client_access hash:/etc/postfix/allowed_clients
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/allowed_senders

          • [^] # Re: petite question

            Posté par  (site web personnel) . Évalué à 2.

            Beurk. Heureusement que le courrier électronique s'est développé comme système ouvert.

            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  . Évalué à 3. 

      <vendredi_soir>
GPG
</vendredi_soir>

  • # Clé publique

    Posté par  . Évalué à 2.

    Il faut faire attention à se placer dans un dossier uniquement lisible par le démon dkim, pour éviter que la clef publique soit lisible par tous.

    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.

  • # Tuto sympa

    Posté par  (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  (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  . É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  (site web personnel) . Évalué à 2.

        mouai perso j'ai pas envie d'attendre pour recevoir un mail

        • [^] # Re: solution antispam

          Posté par  (site web personnel) . Évalué à 7.

          Il y a des filtres de liste grise qui évitent l'attente en exemptant d'attente :

          1. les serveurs déjà vus, pendant quelques jours ;
          2. les messages valides en SPF ;
          3. les serveurs présents sur des listes blanches connues.

          • [^] # Re: solution antispam

            Posté par  (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  (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

  • # Journal et auto-répondeurs

    Posté par  (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  . É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 ipv6
    est 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  (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  (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  (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  (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 :

    • bonjour je suis $HOSTNAME
    • dig $HOSTNAME donne IP de la machine
    • dig -x $IP donne $HOSTNAME

    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  (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  (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  . Évalué à 3.

          An SMTP server MAY verify that the domain name argument in the EHLO
          command actually corresponds to the IP address of the client.

          Ça ne correspond qu’aux deux premières lignes de l’exemple que tu donnes :

          bonjour je suis $HOSTNAME
          dig $HOSTNAME donne IP de la machine

          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  (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  (site web personnel) . Évalué à 2.

      Afin que les emails soient envoyés doucement.

      C'est à dire? (oui, des chiffres!)

      • [^] # Re: Deux trois choses

        Posté par  . Évalué à 0.

        Afin que les emails soient envoyés doucement.

        C'est à dire? (oui, des chiffres!)

        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  (site web personnel) . Évalué à 2.

        C'est à dire? (oui, des chiffres!)

        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  (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  . É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  . É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  (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  (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  (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  . Évalué à 7.

      Il y a La Poste

    • [^] # Re: Beaurk

      Posté par  (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  . É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  (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  . É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  (site web personnel) . Évalué à 2.

        Yunohost ?

  • # Merci !

    Posté par  . É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  . É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 !!

  • # Port 24 ou 2424 ?

    Posté par  (site web personnel) . Évalué à -1. 

    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

    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  . Évalué à 4.

      Seul endroit où est indiqué le port 24, n'est-ce pas le port 2424 ?

      Non, on envoie les message à Dovecot qui écoute sur le 24.

      Étant derrière un nat, dois-je FWD également le port 24 vers ma VM MAIL?!

      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  (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 :

        ==> /var/log/dspam/dspam.debug <==
18622: [10/30/2013 20:19:03] DSPAM Instance Shutdown.  Exit Code: 0
18622: [10/30/2013 20:19:03] checking trusted user list for dspam(109)

==> /var/log/mail.log <==
Oct 30 19:19:03 localhost postfix/lmtp[18660]: 119CB400F5: to=<nono@m0le.net>, relay=127.0.0.1[127.0.0.1]:2424, delay=0.22, delays=0.13/0/0.05/0.05, dsn=2.6.0, status=sent (250 2.6.0 <nono@m0le.net> Message accepted for delivery)
Oct 30 19:19:03 localhost postfix/qmgr[25604]: 119CB400F5: removed

        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  (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 :

        ServerParameters "--deliver=innocent,spam"

        dans /etc/dspam/dspam.conf

        et définir

        postmaster_address = user@example.net

        dans /etc/dovecot/conf.d/15-lda.conf

        • [^] # Script Sieve

          Posté par  (site web personnel) . Évalué à 1.

          Et, je pense qu'il manque le "require" dans le script sieve :

          require ["fileinto"];

          sous peine de se retrouver avec un joli

          main script: line 2: error: unknown command 'fileinto' (only reported once at first occurence).
          main script: error: validation failed.

  • # package

    Posté par  . É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.