La façon la plus simple de configurer un serveur de messagerie IMAP sécurisé? [fermé]

17

Je voudrais me débarrasser de Google en tant que fournisseur de messagerie et mettre en place une solution de messagerie complète sur mon serveur dédié. Le problème: je souhaite que la configuration soit aussi simple que possible, afin qu'il ne soit pas difficile de tout recommencer en cas de problème.

Conditions préalables

  • Un seul compte utilisateur sur la machine.
    • (nom diti; e-mail principal [email protected]; les autres alias sont redirigés mais un client de messagerie peut gérer les différents alias et réagir en conséquence)
  • N'utilise de préférence pas MySQL.
    • (en cas de sauvegarde et de restauration de données ainsi que par souci de simplicité, il est préférable de ne pas installer et sécuriser MySQL avant d'obtenir un serveur de messagerie fonctionnel)
  • Le courrier électronique est accessible (IMAP et SMTP) de l'extérieur.
  • Chiffrement SSL / TLS pour l'authentification IMAP et SMTP (j'utilise des certificats CAcert , est-ce important?).

Je crois que la simplicité, l'accès IMAP / SMTP et l'authentification sécurisée sont les fonctionnalités «de base» que tout le monde désireux de quitter Google / quoi que ce soit d'autre voudrait. Si je me trompe et qu'il existe une solution plus simple (par exemple, une solution de type ownCloud, avec tout inclus), je serais heureux d'entendre.

Je pense que la combinaison de Postfix et Dovecot serait la voie à suivre. Soit dit en passant, j'utilise Debian.

Les informations que j'ai trouvées jusqu'à présent

  • Un article en français décrit de manière très détaillée comment configurer une solution de messagerie électronique complète et sécurisée. Il est long, plus difficile à maintenir, plus difficile à sauvegarder et à restaurer, etc. De plus, un cache DNS est-il nécessaire?
  • Le wiki Gentoo ( Complete_Virtual_Mail_Server/SSL_Certificatespage) mentionne l'utilisation des certificats CAcert, mais n'est pas clair à ce sujet (tous ces SubjectAltNamesous-domaines sont -ils nécessaires?), Ni il utilise Postfix (j'ai lu que Courier est plus difficile).
  • Divers tutoriels sur l'auto-hébergement, tous différents, décrivant rarement ce qu'ils font et pourquoi (les e-mails auto-hébergés avec accès à distance semblent compliqués à configurer, alors pourquoi simplement fournir une liste de commandes sans explication pour les "nuls?")) .

J'espère que j'ai demandé les bonnes choses et qu'elles ne sont pas trop idiotes.

Diti
la source
1
Avez-vous une idée de la façon dont cette question pourrait être reformulée et rouverte?
Diti

Réponses:

19
  • Non, il n'est pas nécessaire de configurer un cache DNS sur le serveur. Le serveur doit utiliser un résolveur DNS de mise en cache quelque part à proximité, mais la plupart des sociétés d'hébergement exécutent déjà leurs propres résolveurs pour l'ensemble du centre de données et configurent les serveurs pour les utiliser par défaut.

  • Par défaut, Postfix et Dovecot utilisent des comptes locaux pour tout. Si vous avez un compte Linux nommé diti, vous pouvez vous connecter à Dovecot avec lui, et vous pouvez configurer Postfix pour valider les connexions SMTP avec Dovecot .

  • Si vous êtes d'accord pour que tous les messages soient /etc/aliasesdirigés vers le même compte, vous pouvez configurer des alias simples (comme dans, ) pour rediriger le courrier pour kra@ou postmaster@vers le diticompte.

  • Tous ces subjectAltNames ne sont pas nécessaires. Les seuls dont vous avez besoin sont pour les noms de domaine que vous allez réellement utiliser , par exemple mail.diti.meou glaux.diti.me. Je ne sais pas si vous devez inclure le domaine lui-même (c. diti.me-à-d.).


Ce qui suit suppose que le domaine possède déjà des enregistrements MX configurés pour pointer vers ce serveur. J'essaie généralement de garder ma configuration raisonnablement claire, car je finis toujours par me demander "à quoi bon ça sert" quelques mois plus tard.

1. Tout d'abord, installez les packages postfixet dovecot-imapd. Lorsque vous êtes invité à propos de la configuration de Postfix, sélectionnez l'option "Site Internet" et entrez diti.mecomme nom de messagerie. À ce stade, vous pouvez déjà envoyer et recevoir du courrier en tant que [email protected], et probablement même vous connecter à IMAP.

Cependant, il n'a pas encore SSL, ni autorise l'envoi de courrier via SMTP de l'extérieur, ni un endroit sain pour stocker le courrier (la valeur par défaut est un fichier mbox /var/mail, ce qui n'est pas fiable et donne de mauvaises performances, en particulier avec IMAP).

2. Si vous avez déjà un certificat SSL, insérez /etc/ssl/private/diti.me.pem-le et saisissez la clé privée /etc/ssl/private/diti.me.key. L'emplacement exact n'a pas vraiment d'importance, mais /etc/ssl/privatec'est là que Debian les conserve.

Assurez-vous que les deux fichiers appartiennent et sont lisibles par le ssl-certgroupe, afin que Postfix et Dovecot puissent y accéder. Ajoutez également les comptes des deux démons à ce groupe à l'aide de gpasswd -a.

3. Le Postfix généré automatiquement par Debian main.cfest aussi un peu compliqué, donc je vais juste publier une version minimale nettoyée:

# Informations sur le serveur
mondomaine = diti.me
myorigin = $ mydomain
  # Divers autres paramètres utilisent ces deux variables comme valeurs par défaut.

# Service SMTP
smtpd_tls_security_level = peut
smtpd_tls_cert_file = /etc/ssl/private/diti.me-mail.pem
smtpd_tls_key_file = /etc/ssl/private/diti.me-mail.key
  # Cela permet d'utiliser STARTTLS sur toutes les connexions SMTP entrantes.
  # Notez que `postfix` doit être ajouté au groupe` ssl-cert` pour pouvoir
  # pour accéder aux fichiers dans / etc / ssl / private.

# Stratégies
mynetworks = [:: 1] / 128, 127.0.0.0/8, [::ffff:127.0.0.0 4.0 / 10
  # Ceci répertorie les adresses IP qui sont considérées comme "de confiance" et peuvent utiliser
  # ce serveur pour envoyer du courrier vers l'extérieur (c'est-à-dire vers d'autres domaines). Par
  # par défaut, seul "localhost" est autorisé. De tout le monde, envoyez un courrier à
  # domaines dans $ mydestination seront acceptés.
mydestination = $ mydomain, localhost
  # Liste des domaines pour lesquels accepter le courrier, à partir de n'importe quelle adresse IP. 
# Livraison
alias_maps = hachage: / etc / aliases
  # Cela conserve les alias à l'échelle du système. Il est bon de le définir explicitement car
  # la valeur par défaut inclut parfois NIS, ce qui n'a pas de sens.
recipient_delimiter = +
  # Indique à postfix de diviser la partie locale des adresses au premier '+',
  # soi-disant "plus-adressage": le courrier envoyé à diti + foo @ sera livré
  # à la boîte aux lettres diti @.

Pour Dovecot, Debian utilise simplement les exemples de configuration par défaut, et ils sont assez bons, avec chaque option décrite.

Chaque fois que vous modifiez la configuration, rechargez les démons avec postfix reloadet / ou doveadm reload.

4. Par défaut, Postfix livre le courrier à /var/mail/$USERla Mbox format, ce qui est assez simple (vous pouvez voir facilement avec un éditeur de texte) , mais a beaucoup de problèmes, en particulier avec IMAP, puisque le fichier entier doit être réécrite à chaque fois que vous déplacez un message ou même en marquer un comme "lu" ou "non lu".

Modifiez les deux démons pour utiliser Maildir. (Il existe d'autres formats, mais ils ont tendance à être spécifiques au serveur MTA ou MDA ou IMAP ou autre; Maildir est largement pris en charge.)

Dans /etc/postfix/main.cf, ajoutez ce qui suit à la section "Livraison":

home_mailbox = Mail /

Configurez Dovecot pour utiliser le même chemin, dans /etc/dovecot/conf.d/10-mail.conf:

mail_location = maildir: ~ / Mail

5. À un moment donné, vous devez indiquer à Dovecot d'utiliser SSL également. Les paramètres appropriés sont disponibles /etc/dovecot/conf.d/10-ssl.conf. En fait, le paquet Debian pour Dovecot utilise déjà SSL, bien qu'avec un certificat auto-signé qui soit pour la plupart inutile. Configurez-le pour utiliser votre propre certificat:

ssl = oui

ssl_cert = </etc/ssl/private/diti.me-mail.pem
ssl_key = </etc/ssl/private/diti.me-mail.key

6. Vous pouvez maintenant envoyer du courrier à l'extérieur et le recevoir. Il est toujours nécessaire de configurer Postfix pour vous permettre d'envoyer de l' extérieur en vous connectant avec votre client de messagerie via SMTP.

Dites d'abord à Postfix d'utiliser Dovecot pour vérifier les connexions. Les instructions suivantes sont principalement tirées du wiki de Dovecot .

Dovecot a /etc/dovecot/conf.d/10-master.confbesoin d'écouter sur une socket à laquelle Postfix pourrait accéder; la configuration par défaut a déjà un exemple commenté:

authentification de service {
    ...
    unix_listener / var / spool / postfix / private / auth {
        mode = 0660
        user = postfix
        groupe = suffixe
    }
    ...
}

Et Postfix doit l'utiliser à /etc/postfix/main.cfnouveau:

# Authentification
smtpd_sasl_type = pigeonnier
smtpd_sasl_path = private / auth
  # L'autre type possible est "cyrus", pour le Cyrus SASL 'saslauthd'
  # démon. Je choisis Dovecot ici car il fonctionne bien comme serveur SASL, et
  # il est plus simple de le laisser gérer l'authentification pour les deux démons.

7. Notez que ce qui précède ne s'est installé smtpd_sasl_auth_enablenulle part. La convention actuelle consiste à ne pas activer l'authentification SMTP globalement, mais à conserver tcp / 25 uniquement en tant que port SMTP "de serveur à serveur". Pendant ce temps, les nouveaux messages des utilisateurs sont acceptés via SMTP sur TCP / 587, le port de "soumission de courrier", qui nécessite une authentification. Certains FAI bloquent même tcp / 25 à cause du spam, mais gardent tcp / 587 ouvert car il est généralement mieux sécurisé.

Activez le port "Submission" dans /etc/postfix/master.cf, avec l'authentification SASL. La valeur par défaut a master.cfdéjà les lignes nécessaires qui doivent simplement être non commentées, bien que certaines d'entre elles doivent toujours être omises.

soumission inet n - - - - smtpd
  -o syslog_name = postfix / soumission
  -o smtpd_tls_security_level = chiffrer
    # Le port "Submission" nécessitera TLS, au lieu de le rendre facultatif
  -o smtpd_sasl_auth_enable = oui
    # ... ainsi que permettre aux utilisateurs de se connecter.
# -o smtpd_reject_unlisted_recipient = no
# -o smtpd_client_restrictions = $ mua_client_restrictions
# -o smtpd_helo_restrictions = $ mua_helo_restrictions
# -o smtpd_sender_restrictions = $ mua_sender_restrictions
    # Ces quatre options peuvent être laissées en commentaire; s’ils étaient activés, ils
    # attendez-vous à ce que vous définissiez des règles de restriction personnalisées dans 'main.cf', mais le
    # ceux par défaut sont très bien.
  -o smtpd_recipient_restrictions = permit_sasl_authenticated, rejeter
    # Les destinataire_restrictions par défaut vérifient l'adresse IP et
    # $ mydestination. Pour le port "Soumission", autorisez tout aussi longtemps
    # lorsque l'utilisateur est connecté, mais rejetez tous les messages anonymes.
  -o milter_macro_daemon_name = ORIGINAIRE
    # Si vous décidez ultérieurement de configurer un proxy DKIM ou autre, cela permettra
    # pour distinguer les courriers envoyés par les utilisateurs des courriers reçus.
    # Cela fait partie de la configuration par défaut, donc inclus ici aussi.

Si vous avez un client de messagerie qui nécessite un port "implicite SSL" à l'ancienne (tcp / 465), vous pouvez décommenter les smtpslignes master.cf- si vous le faites, conservez les paramètres similaires à ceux du submissionport.

8. Enfin, définissez des alias pour votre compte, en les modifiant /etc/aliases. L' postmasteralias est fondamentalement requis; c'est le point de contact en cas de problème avec votre serveur de messagerie. Le pointage rootet autres alias similaires sont également bons.

Le format de base est documenté dans des alias (5):

postmaster: root
admin:      root
root:       diti
kra:        diti

Utilisez postaliasou newaliasespour mettre à jour la base de données hachée /etc/aliases.dbchaque fois que vous modifiez ce fichier.

Maintenant, vous avez toujours un compte appelé ditien ce qui concerne Postfix et Dovecot, mais le courrier envoyé à y kra@...est également transféré. Certains clients de messagerie (par exemple Thunderbird) prennent en charge plusieurs "identités" ou "personas" pour un seul serveur de messagerie, vous pouvez donc choisir entre différentes adresses "De:".

C'est à peu près ça. Je pourrais revenir avec des instructions pour procmail, domaines virtuels, SPF et / ou DKIM plus tard.

user1686
la source
1
C'est super ! C'est vraiment le tutoriel le plus simple sur l'auto-hébergement de messagerie. La partie qui m'a le plus étonné était de voir, au point 1, que je pouvais en effet déjà envoyer et recevoir des e-mails de / vers mon serveur. Quoi qu'il en soit, je vais modifier votre message pour clarifier certains points aussi! Cependant, je n'arrive pas à configurer mon e-mail de l'extérieur (je veux dire Thunderbird). J'utilise mail.diti.me(= l'adresse IP de mon serveur) pour IMAP et SMTP, mon domaine a déjà les enregistrements MX. Ai-je fait quelque chose de mal pendant la configuration de mon serveur, ou ai-je simplement des problèmes avec Thunderbird?
Diti
@Diti: Il semble que tous les ports pertinents (à l'exception de tcp / 25) soient pare - feu sur votre serveur.
user1686
Quelle devrait être la sortie de ps auxw | grep "dovecot"? J'ai comparé avec une configuration complexe de mes amis, et il l'a fait dovecot-authet imap-loginque je n'ai pas. Serait-il possible que les ports soient réellement ouverts (je ne me souviens pas avoir utilisé un pare-feu), mais sans démon configuré pour écouter ces ports de l'extérieur, ou quelque chose? Lorsque je cours openssl s_client -connect mail.diti.me:993sur le serveur, cela fonctionne (et dit "Dovecot ready."), Mais rien de l'extérieur. Peut-être que je devrais essayer d'installer un pare-feu et autoriser explicitement ces ports?
Diti
@Diti: l'architecture de Dovecot considérablement changé entre v1 et v2, vous verrez différents processus - v2, il y aura dovecot, dovecot/anvil, dovecot/loget d' autres. De plus, certains processus ne sont démarrés que lorsque quelqu'un se connecte, ou uniquement lors de la vérification des détails d'authentification.
user1686
1
@Diti: Non, les deux démons écoutent par défaut sur toutes les interfaces et toutes les adresses. Mais les connexions ne sont pas refusées - le serveur abandonne plutôt silencieusement toutes les tentatives de connexion (voir l'analyse nmap à laquelle je suis lié), ce qui est un signe certain d'un pare-feu quelque part. Essayez d'utiliser iptables -n -v -Lpour vérifier s'il existe des règles pour supprimer les paquets.
user1686