Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
pratique:informatique:mail:serveur_mail2 [22/09/2024 11:55] – [Dovecot] sieve Zatalyzpratique:informatique:mail:serveur_mail2 [10/10/2024 12:33] (Version actuelle) – [Todo] Zatalyz
Ligne 753: Ligne 753:
 Postfixadmin étant un clicodrôme parfait, je vous laisse explorer.  Postfixadmin étant un clicodrôme parfait, je vous laisse explorer. 
  
 +
 +===== Paramétrer les alias systèmes vers admin@ =====
 +C'est bien beau tout ça, mais quand un mail interne au système (par exemple à root) est envoyé, il arrive où ? Nul part, et cette fois pas question de jouer avec [[pratique:informatique:mail:mail_relai|Msmtp]] : le relai, ça sera "nous". Mais, la logique n'est pas très différente.
 +
 +On commence par éditer ''/etc/aliases'' :
 +<code txt /etc/aliases>
 +mailer-daemon: postmaster
 +postmaster: root
 +nobody: root
 +hostmaster: root
 +usenet: root
 +news: root
 +webmaster: root
 +www: root
 +ftp: root
 +abuse: root
 +noc: root
 +security: root
 +default: admin@example.org
 +root: admin@example.org
 +</code>
 +
 +Oui, sans le @ à la fin des alias, cette fois. Et vers admin@example.org ou autre, hein, tant que c'est un utilisateur présent sur le système. 
 +
 +Puis on régénère le fichier de postfix à propos des alias :
 +  postalias /etc/aliases
 +
 +Et on peut tester l'envoi d'un mail. J'ai craqué, installé ''bsd-mailx'' (dont la syntaxe pour l'envoi d'un mail test ne me pose pas de souci) et hop :
 +  echo "Test" | mail -s "Test " root
 +
 +Cela arrive bien dans la boite mail configurée !
  
 ===== Tester ===== ===== Tester =====
-À ce stade, on va pouvoir voir à quel point ça marche (ou pas). +On va pouvoir voir à quel point ça marche (ou pas).  
 + 
 +<WRAP center round tip 60%> 
 +Les infos ici peuvent être utilisées à divers stade du tutoriel pour voir ce qui marche.  
 +</WRAP>
  
 Ajoutez un domaine sur l'interface de postfixadmin, et un utilisateur (ici, moi@example.org). En théorie, déjà, c'est possible... Ajoutez un domaine sur l'interface de postfixadmin, et un utilisateur (ici, moi@example.org). En théorie, déjà, c'est possible...
Ligne 777: Ligne 812:
   * Vérifier que ''/var/vmail/'' s'est peuplé d'une nouvelle boite. Et avec mutt on peut lire le "message"   * Vérifier que ''/var/vmail/'' s'est peuplé d'une nouvelle boite. Et avec mutt on peut lire le "message"
  
-À ce stade, tout s'est passé en interne, et c'est déjà pas si mal. +Jusque là, tout s'est passé en interne, et c'est déjà pas si mal. 
  
 Pour tester les limites de quota, créez un utilisateur avec un quota très bas (par exemple 1 Mo), puis créer un fichier à joindre "volumineux", et enfin envoyez-le (avec mutt) : Pour tester les limites de quota, créez un utilisateur avec un quota très bas (par exemple 1 Mo), puis créer un fichier à joindre "volumineux", et enfin envoyez-le (avec mutt) :
Ligne 790: Ligne 825:
   mutt -f imaps://moi@exemple.org@mail.exemple.org   mutt -f imaps://moi@exemple.org@mail.exemple.org
  
-Prochain test : envoyer un mail à l'extérieur.+<WRAP center round tip 100%> 
 +Envie de tester encore et encore, en changeant le sujet seulement pour voir ce qui passe ou pas ? J'ai un petit script bash pour ça :  
 +<code bash mailtest.sh> 
 +#!/bin/bash
  
 +# Vérifie si le sujet a été fourni en argument
 +if [ -z "$1" ]; then
 +    echo "Usage: $0 <sujet>"
 +    exit 1
 +fi
 +
 +# Assigne le sujet à une variable
 +subject="$1"
 +
 +# Définis le corps du message
 +body="Test de quota"
 +
 +# Chemin vers le fichier à joindre (quand on teste les quotas)
 +#attachment="./fauxfichiers/400kb.txt"
 +
 +# Adresse e-mail du destinataire
 +recipient="moi@example.org"
 +
 +# Envoie l'e-mail avec pièce jointe
 +# echo "$body" | mutt -s "$subject" -a "$attachment" -- "$recipient"
 +# OU sans la pièce jointe
 +echo "$body" | mutt -s "$subject" -- "$recipient"
 +echo "Yep"
 +
 +</code>
 +
 +Il suffit ensuite de lancer le script en lui filant un sujet entre guillemets :
 +<code>./mailtest.sh "sujet de 12h02"</code>
 +</WRAP>
 +
 +
 +
 +==== Todo ====
 +<del>Prochain test : envoyer un mail à l'extérieur. Ce qui demande que j'ouvre des ports sur la box, c'est pas de suite.</del> : fait :)
 +
 +Il va falloir configurer dkim et tout l'toutim.
 +
 +Tester aussi si je peux envoyer un message avec un de mes alias ET si je suis bloquée si je tente d'utiliser un autre alias du domaine sans le bon compte.
 +
 +Problème pour envoyer un message à "nimporte qui sauf moi". Revoir la conf... 
  
 ===== vieux tuto ===== ===== vieux tuto =====
Ligne 815: Ligne 893:
  
  
- 
-===== Paramétrer les alias systèmes vers admin@ ===== 
-C'est bien beau tout ça, mais quand un mail interne au système (par exemple à root) est envoyé, il arrive où ? Nul part, et cette fois pas question de jouer avec [[pratique:informatique:mail:mail_relai|Msmtp]] : le relai, ça sera "nous". Mais, la logique n'est pas très différente. 
- 
-On commence par éditer ''/etc/aliases'' : 
-<code txt /etc/aliases> 
-mailer-daemon: postmaster 
-postmaster: root 
-nobody: root 
-hostmaster: root 
-usenet: root 
-news: root 
-webmaster: root 
-www: root 
-ftp: root 
-abuse: root 
-noc: root 
-security: root 
-default: admin@example.org 
-root: admin@example.org 
-</code> 
- 
-Oui, sans le @ à la fin des alias, cette fois. Et vers admin@example.org ou autre, hein, tant que c'est un utilisateur présent sur le système.  
- 
-Puis on régénère le fichier de postfix à propos des alias : 
-  postalias /etc/aliases 
- 
-Et on peut tester l'envoi d'un mail. J'ai craqué, installé ''bsd-mailx'' (dont la syntaxe pour l'envoi d'un mail test ne me pose pas de souci) et hop : 
-  echo "Test" | mail -s "Test " root 
- 
-Cela arrive bien dans la boite mail configurée ! 
  
  
Ligne 1293: Ligne 1340:
 https://workaround.org/bullseye/filtering-out-spam-with-rspamd/ https://workaround.org/bullseye/filtering-out-spam-with-rspamd/
  
-===== Filtres SIEVE ===== 
-Cela va permettre de créer des règles de filtre sur le serveur et donc de trier automatiquement les emails sans lien avec le client courriel. Pratique quand on switche entre webmail et divers thunderbird. 
- 
-En principe ce qu'on a déjà fait suffit en bonne partie, mais il vient le moment de le tester, et surtout de permettre de gérer ces filtres via un client mail (et ce sera plutôt via notre webmail snappymail que via thunderbird dont l'extension ne marche plus).  
- 
-Il faut modifier ''/etc/dovecot/conf.d/20-managesieve.conf'' et décommenter les lignes suivantes : 
-<code> 
-protocols = $protocols sieve 
- 
-service managesieve-login { 
-  inet_listener sieve { 
-    port = 4190 
-  } 
- 
-  service_count = 1 
-} 
-</code> 
- 
-Décommenter aussi cette ligne dans ''/etc/dovecot/conf.d/10-auth.conf'' : 
-<code>disable_plaintext_auth = yes 
-</code> 
- 
-Relancer Dovecot, puis vérifier que les ports sont bien ouverts :  
-  service dovecot restart 
-  lsof -i :4190 -P 
- 
-Cela devrait donner ce genre de retour 
-<code> 
-COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME 
-dovecot 371602 root   15u  IPv4 487495      0t0  TCP *:4190 (LISTEN) 
-dovecot 371602 root   16u  IPv6 487496      0t0  TCP *:4190 (LISTEN) 
-</code> 
-Il faut qu'iptable laisse passer ça **aussi** : 
- 
-  iptables -A INPUT -p tcp --dport 4190 -j ACCEPT 
-  netfilter-persistent save 
- 
-Il faut aussi permettre à ce port d'être accessible à travers le firewall/proxy/box (mais là, ça dépend de la box etc, donc pas de tuto ici...). 
  
-Et voilà, plus qu'à configurer le port et la possibilité d'utiliser SIEVE sur notre client mail favori, ça marche ! 
 ===== Encore à faire ===== ===== Encore à faire =====
   * Paramétrage de rspamd, juste pour gérer les spams.    * Paramétrage de rspamd, juste pour gérer les spams. 
CC Attribution-Noncommercial-Share Alike 4.0 International Driven by DokuWiki
pratique/informatique/mail/serveur_mail2.1726998942.txt.gz · Dernière modification : 22/09/2024 11:55 de Zatalyz