Yunohost + messagerie

Bonjour,

J’ai un VPS (sur lequel j’ai installé yunohost) + nom de domaine. J’aimerais l’utiliser comme messagerie principale (pour le boulot, les impôts…).
Mais quand je regarde la messagerie, cela semble assez basique…est-ce qu’il y a des trucs à connaître pour mettre en place une messagerie digne de ce nom tant sur la sécurité (spam, donnée cryptée…) que sur la forme (contacts, dossiers,…)

Bonjour,

Yunohost vient par défaut avec Postfix,Dovecot, Rspamd et configure le tout avec tout ce qu’il faut concernant le mail (spf, dkim,dmarc)

Je ne comprends pas ce que tu veux dire par “cela semble basique”, il y a tout ce qu’il faut.
Pour la forme et les données cryptées, ça va dépendre du client que tu utilises. Et pour gérer les contacts, il faut faire appel à une application telle que baïkal par exemple ou d’utiliser les fonctions webdav de Nextcloud.

j’utilise le mail du serveur Yunohost (serveur à domicile) sans difficulté majeure mais ça ne semble pas le cas de tout le monde. L’antispam fonctionne très bien me concernant, malgré tout un certain nombre de sujets sur le forum se plaigne d’une configuration trop laxiste pour celui-ci.

Les mails sont bien acceptés hormis avec microsoft qui les considèrent trop souvent comme des spams bien que ce soit de moins en moins le cas. Yahoo les refuse depuis leur changement de politique car j’utilise un sous-domaine (NDD offert par yunohost).

Voilà pour l’essentiel, mais le mail est vraiment la partie la plus aléatoire, tu peux avoir du tout bon comme des refus selon ton IP, ton hébergeur… et ça ne dépend pas forcément de toi mais plutôt de l’agressivité des mails destinataires appartenant bien souvent aux gafam qui dictent leurs lois.

Bonjour, pour compléter, il est très important de bien configurer sa zone DNS (SPF, DMARC, DKIM). Merci à Yunohost qui aide d’ailleurs fort bien.
Il est aussi important de configurer le reverse-dns (qui consiste à faire pointer son nom de domaine à partir de l’ipv4 et ipv6), ce qui se fait côté fournisseur de VPS, et non côté fournisseur de nom de domaine.
Pour ma part, avec mon domaine chez OVH et mon VPS chez Hostinger, tout fonctionne bien (ai-je de la chance?). Parfois, le disgnostic m’avertit qu’il n’y a pas de reverse-dns en ipv6, message qui disparaît au diagnostic suivant.
Bon courage !

Bonjour,

Je ne m’y connais pas trop en serveur mail, mais quand je compare ma boîte yunohost et ma boîte pro ou zaclys sur thunderbird, il y a des différences : envoie de mail retardé, brouillon, spam, redirection automatique. Mais il s’agit peut être de réglages à faire ou même de paramétrer le client de messagerie et non le serveur.

Mais j’ai un pb plus important, j’ai fait tous les réglages comme il faut (DNS, reverse-DNS) et je peux envoyer des mails par contre impossible d’en recevoir. J’ai testé avec 3 ou 4 de mes autres mails, message d’erreur

<<< 554 5.7.1 Service unavailable; Client host blocked using cbl.abuseat.org; Error: open resolver; DNSBL Error Code - Open/public resolver - The Spamhaus Project
554 5.0.0 Service unavailable
<<< 554 5.5.1 Error: no valid recipients

Quant je clique sur le lien, il est indiqué que le pb vient de la boîte de reception (donc mon serveur mail) mais je ne vois pas quoi faire.

Ton problème est lié au fait que tu utilises des DNS ouverts. Sur l’aspect technique, je ne peux pas te renseigner ne maîtrisant pas le sujet. Voici des liens qui peuvent t’aider, d’autant plus que @tituspijean y apporte une solution avec OVH. Peut-être pourra-t-il t’aider si tu as des difficultés à résoudre le problème.

Il y a bien les dossiers brouillon, spam. Peut-être sont-ils crées la 1ère fois que tu en as besoin? Je ne saurais te le dire, je les ai bien me concernant que ce soit sur snappymail (client web disponible dans les applications yunohost) ou sur thunderbird. Essaye de faire un brouillon et de marquer un mail en spam avec thunderbird et tu verras bien si les dossiers sont crées.
La redirection automatique peut être directement paramétrée dans la webadmin de yunohost. Pour l’envoi de mails retardés, il y a une extensions qui le fait si tu utilises thunderbird. Je connais cette fonction sur le webmail Gmail, par contre je ne pense pas que tu puisses le faire à partir de thunderbird même en utilisant ce type de mail sans l’extension. Du moins c’est ce que je crois, je n’ai jamais essayé.

Merci pour toutes ces infos, je vais partir de là pour trouver une solution. J’ai fait une demande en parallèle sur le forum ovh, je mets ici la réponse si ça peut aider d’autres personnes dans ma situation (pour le moment cela ne m’aide pas mais je vais creuser chaque piste et revenir ici pour décrire ce que j’ai fait et le résultat)

Que contient votre fichier /etc/resolv.conf ?
search openstacklocal
Que renvoie cette commande ?: host 2.0.0.127.xbl.spamhaus.org
Host 2.0.0.127.xbl.spamhaus.org not found: 3(NXDOMAIN)

Vous ne pouvez donc pas utiliser spamhaus xbl/cbl/zen comme ça. Vos requêtes DNS sont agglomérées sur un serveur qui s’occupe aussi de plein d’autres clients, et ça excède les limites admissible par Spamhaus pour un usage privé ou TPE.
Vous avez 3 possibilités:

  • ne plus utiliser spamhaus pour filtrer vos mails entrants
  • voir si la commande: host 2.0.0.127.xbl.spamhaus.org 127.0.0.1 fonctionne, ce qui voudrait dire que vous avez un résolveur local, et dans ce cas modifier /etc/resolv.conf pour utiliser votre résolveur local
  • obtenir un identifiant personnel chez Spamhaus, c’est gratuit, mais je ne me rappelle plus où on doit le - mettre dans la config postfix. Il faut lire les docs et je pense que ça a déjà été dit ici.

D’après tes liens spamhaus interdit les DNS publics et que yunohost les utilisent…
Quel risque ou conséquences à ne pas utiliser les DNS publics ?
Quel risque à ne pas utiliser spamhaus ?

Premier test, j’ai suivi les consignes sur cette page + inscription sur spamhaus

https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html

Déla éventuel…mais pas de modif immédiate

Option 2 proposée aussi par spamhaus avant de s’enregistrer chez eux :

Remove the existing Spamhaus Project DNSBL configuration from your MTA. Ce que j’ai fait ainsi :

/etc/postfix/main.cf

#    reject_rbl_client bl.spamcop.net,
#    reject_rbl_client cbl.abuseat.org,
#    reject_rbl_client zen.spamhaus.org,

Cela fonctionne, mais est-ce risqué d’avoir supprimer ces filtres. Théoriquement spamhaus devrait répondre et me permette de configurer tout cela.

Nope nope nope… C’est la faute de la configuration automatique des VPS d’OVH ça. C’est eux qui injectent la ligne search openstacklocal dans ton /etc/resolv.conf.

J’ai désactivé ça, et le mien ne contient plus que nameserver 127.0.0.1, à part des lignes commentées.

J’avais essayé deux choses:

  1. La première, plus précise, est d’empêcher la modification de resolvconf.
    Crée un fichier /etc/cloud/99-disable-resolvconf.cfg avec comme texte: manage-resolv-conf: false
    Un redémarrage est conseillé pour s’assurer que c’est désactivé (en vérifiant le contenu de /etc/resolv.conf

  2. Si ça n’a pas marché, désactivons complètement cloud-init avec touch /etc/cloud/cloud-init.disabled.
    Idem, redémarre le système et vérifie. Attention, de mémoire j’avais dû reconfigurer à la main l’IPv6 (eh oui, c’est géré par le cloud-init).


Bon après l’avoir réessayé moi-même, c’est l’option bourrine qui marche le mieux. :slight_smile: L’option 1 seule laisse un nameserver 213.186.33.99 qui est le DNS d’OVH.

1 Like

Le mail de confirmation spamhaus n’arrive pas mais tous les autres mails arrivent désormais…je pense que je vais me passer de spamhaus. On verra bien si je reçois bcp de spam.

Tu sais que tu peux éditer tes messages, pas la peine de multi-poster, ça n’aide pas à la lecture. :wink:

C’est vrai…mais j’aimais l’idée de proposer cela en épisodes à suivre :grin:

Réponse finale :

  • j’ai testé le protocole proposé par spamhaus (mais difficile de tout comprendre)
  • j’ai testé les proposition de @tituspijean
  • deux trois autres modif

La meilleures solutions (pour le moment) désactiver spamhaus comme je l’ai fait plus haut en mettant en com les 3 lignes dans main.cf

J’ai un message d’erreur sur le diagno yunohost, je ne sais pas ce que cela implique en terme de spam…mais je reçois enfin les mails.

Je ne sais pas si cette solution est satisfaisante mais pour le moment, à part abandonner OVH, je n’ai pas mieux…et pris d’un doute, je vérifie main.cf sur mon serveur ecowan, et il y a exactement le même réglage, suppression de spamhaus. Il semblerait que ce soit LA solution :slight_smile:

Quel est ton retour sur mes propositions? :thinking:

Bonjour, je suis l’auteur de cette réponse sur le forum OVH.
Dans le passé je montais mes serveurs mail moi-même, j’ai viré ma cuti, et aujourd’hui je suis passé à Yunohost qui fait le boulot de manière exceptionnelle en respectant tous le sstandards.

Je me suis dit que l’utilisation des DNS publics dans le cas de @Apoptose provient peut-être de sa configuration réseau. Si la configuration se fait via DHCP, peut-être reçoit-il ce serveur d’OVH 213.186.33.99 dans la réponse DHCP, au paramètre “serveur DNS”.

Merci @tituspijean pour la réponse.

Perso j’utilise mon résolveur local, mais je n’ai pas eu le problème de resolv.conf qui ne listait aucun serveur, Il faut dire que j’ai un serveur baremetal et non un VPS, le cloud-init déployé par OVH est peut-être différent.

Bonjour,

@fritz2cat
Perso j’utilise mon résolveur local

Pour le moment, je me passe de spamhaus (solution la plus simple pour un novice). Je veux bien tenter l’utilisation du resolveur local mais concrètement, comment faire ?

Pour revenir à la question de @tituspijean, je n’ai eu aucun retour après les modifs mis à part que les mails ne passaient pas…je dois avouer qu’il y avait peut être l’une ou l’autre modif préalable qui trainaient sur certains fichiers.
Depuis je suis reparti de zéro, grâce à Yunohost j’ai pu replacer les fichiers de config initiaux et la seule modif en place est celle décrite plus haut, placer les 3 lignes spamhaus en commentaire (dans main.cf) pour les désactiver (depuis je n’ai pas eu plus de spam qu’habituellement)

Mon serveur mail est un kimsufi d’entrée de gamme (intel atom, un disque) que j’ai depuis 2013. Il y a déjà eu un crash disque, et une ou plusieurs réinstallations.
Pour le moment il est sous debian 10, et les mises à jour de Yunohost se sont arrêtées (avant le passage du user ‘admin’ à un groupe ‘admins’)
J’ai un autre serveur beaucoup plus couillu et qui est à jour, mais je garde le petit comme mail-relay à cause de son adresse IP qui a acquis une bonne réputation notamment chez les gafam.

Depuis le début, et fort de mon expérience passée, je me suis éloigné du postfix/mail.cf de stock de Yunohost, tout en apportant mes modifications sur le modèle original de Yuno.

J’ai retrouvé le main.cf actuel ici: https://github.com/YunoHost/yunohost/blob/dev/conf/postfix/main.cf
et je vais commenter mes ajouts et modifications:

Ajout de:

delay_warning_time = 4h
bounce_queue_lifetime = 1d
maximal_queue_lifetime = 1d

A l’opposé, je n’ai pas ces lignes-ci qui semblent plus récentes:

smtpd_tls_chain_files =
    /etc/yunohost/certs/{{ main_domain }}/key.pem,
    /etc/yunohost/certs/{{ main_domain }}/crt.pem

tls_server_sni_maps = hash:/etc/postfix/sni

{% if compatibility == "intermediate" %}
# generated 2020-08-18, Mozilla Guideline v5.6, Postfix 3.4.14, OpenSSL 1.1.1d, intermediate configuration
# https://ssl-config.mozilla.org/#server=postfix&version=3.4.14&config=intermediate&openssl=1.1.1d&guideline=5.6

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = medium

# curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam.pem
# not actually 1024 bits, this applies to all DHE >= 1024 bits
smtpd_tls_dh1024_param_file = /usr/share/yunohost/ffdhe2048.pem

tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES25
6-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
{% else %}
# generated 2020-08-18, Mozilla Guideline v5.6, Postfix 3.4.14, OpenSSL 1.1.1d, modern configuration
# https://ssl-config.mozilla.org/#server=postfix&version=3.4.14&config=modern&openssl=1.1.1d&guideline=5.6

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1, !TLSv1.2
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1, !TLSv1.2
{% endif %}

tls_preempt_cipherlist = no
###############################################################################
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

J’ai une ligne qui doit être incompatible avec Yuno version 11:

chez moi: virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf

stock: virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf,ldap:/etc/postfix/ldap-groups.cf

Il y a un ajout qui manque chez moi:

smtpd_sender_login_maps=
 # ...
   # Extra maps for app system users who need to send emails
   hash:/etc/postfix/app_senders_login_maps

J’ai ajouté une ligne client.cidr ici:

# Requirements for the connecting server
smtpd_client_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    cidr:/etc/postfix/client.cidr,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client zen.spamhaus.org,
    permit

Explication: ce fichier permet de bannir une plage d’adresses IP , quand des spammeurs louent des dizaines de VPS avec des adresses IP contigues chez un hébergeur, pour harceler certains de mes utilisateurs.

Extrait de ce fichier client.cidr (j’ai remplacé un octet valide par X) :

104.140.X.0/23  550 Blacklisted. Too many spam incidents and repeated abuse (Eonix)
140.X.0.0/16    550 Blacklisted. Too many spam incidents and repeated abuse (Epicup)
202.138.X.0/24        450 Your e-mails will stay in your queue....

Ensuite j’ai ajouté 2 phrases check_sender_access dans ce paragraphe:

# Requirements for the sender address
smtpd_sender_restrictions =
#    reject_sender_login_mismatch,
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
   check_sender_access pcre:/etc/postfix/sender_access_pcre,
   check_sender_access hash:/etc/postfix/sender_access_hash,
    permit

Voici un exemple du fichier pcre:

/amphiprioninae.be$/ 554 SPAM detected
/wcm-msa.com$/ 554 Sender blacklisted
/\.icu$/ 554 Bad TLD. Too much spam from this address.

et du fichier hash:

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

Voilà… si ça peut donner des idées à d’autres…
N’oubliez la commande postmap et postfix reload quand vous touchez à ces fichiers…
Notez qu’il faudra peut-être aussi installer un package debian (postfix-pcre ? Je ne me rappelle plus)

Bonjour,

C’est intéressant, quand j’aurais un peu plus de motivation, je me prendrai le temps de comprendre comment fonctionne cette partie du serveur et je m’amuserai à le reparamétrer, mais pour le moment je n’ai pas les compétences. Je vais me contenter de faire confiance à Yunohost et résoudre les pb au fur et à mesure de leurs arrivées…

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.