[Résolu] Procmail renomme les dossiers IMAP en BOGUS

[zeroheure]

What type of hardware are you using: VPS bought online
What YunoHost version are you running: 12.0.16
How are you able to access your server: The webadmin
SSH
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: ajouté un domaine dans la conf de Postfix

Describe your issue

Bonjour

J’ai eu plusieurs problèmes successifs avec les courriels depuis la migration vers Yuno 12. Tout marchait bien sur Yuno 10 et 11. Ma configuration particulière pourrait-elle être cause de cela? Quelqu’un peut-il m’aider à analyser, parce que je n’avance plus? Voici la config en place depuis 4 ou 5 ans :

• Un premier VPS accueille un serveur Odoo avec son domaine toto.com
• Un deuxième VPS accueille Yunohost avec le sous-domaine yuno.toto.com
  • le VPS Yunohost est chez un autre hébergeur
  • le VPS Yunohost sert de serveur d’email
  • les adresses courriels sont en user@toto.com

On a donc Odoo et 2 utilisateurs (ma copine et moi) qui relevons les emails sur Yunohost, à la fois via un webmail (Nextcloud et Snappy Mail), des lecteurs de courriels sur bureau et mobile (Kmail, K9mail et Thunderbird) et via Odoo. Tout est en IMAP. Tout marchait bien depuis 5 ans.

Yunohost est configuré avec yuno.toto.com en domaine principal et toto.com ajouté depuis l’interface web à cause des courriels. J’ai sans doute eu tort de faire ça.

Suite au passage à la v12 on a eu des gros problèmes de montée en charge. C’était dû à l’application “souvenirs” de Nextcloud sous PHP 8.3 qui bouffait la Ram et à Kmail qui jouait à la multiplication des pains (des emails) – merci Akonadi.

Le problème a été résolu en virant l’app de Nextcloud et en supprimant à la main les milliers de courriels dupliqués dans les dossiers /var/mail/[user] de Yunohost.

En même temps Odoo (VPS 1) ne pouvait plus expédier de courriels via Yunohost.

Le problème a été réglé en ajoutant toto.com dans le main.cf de Postfix :

#myorigin = /etc/mailname
myhostname = yuno.toto.com
mydomain = toto.com
mydestination =  yuno.toto.com, toto.com, localhost, localhost.localdomain
relayhost =

Le lendemain ou surlendemain, Procmail a renommé en BOGUS.[user].[inode] tous les dossiers /var/mail/[user]. Ces dossiers sont propriété de vmail:mail et avec les droits rwx--S--- (ce qui me paraît normal). Les courriels vont maintenant dans un fichier mbox nommé [user] propriété de [user]:mail avec les droits d’accès rw-rw----

Renommer les dossiers BOGUS en [user], changer les droits, relancer Procmail, Postfix ou Dovecot n’y change rien. Dans les logs, procmail dit seulement qu’il a renommé les dossiers.

Procmail n’a pas de configuration, mais c’est normal si Postfix lui passe tout au vol.

Et là, à force de fouiller, lire des docs et mal dormir, je ne tilte plus rien. Un peu d’aide pour y voir clair ? Tendez moi la main, je vous enverrai des pensées positives!

Share relevant logs or error messages

rien

[zeroheure]

Et voilà, comme toujours il suffit de bien rédiger une demande d’aide, de la relire posément, pour que la lumière se fasse. Bon, la lumière était faible, il fallait cheminer sur la piste des domaines dans le main.cf de Postfix. Je vous explique la solution, parce qu’il vaut mieux comprendre avant d’appliquer:

Si vous rencontrez le même problème, un moteur de recherche vous a sans doute déjà indiqué que Procmail est sensible aux droits d’accès. Procmail travaille avec les droits d’accès de l’utilisateur. Donc pour mettre le courrier dans vos dossiers il faut que vous en soyez propriétaire. Oui mais si vous en êtes propriétaire, Dovecot ne vous laisse plus regarder dedans.
Ça se mord la queue hein ?
La solution est dans Postfix.
Oui mais c’est Procmail qui … alors pourquoi regarder dans Postfix ? parce que Postfix délègue à Procmail la délivrance des courriels dans les dossiers du serveur.

Un peu plus bas dans la conf de Postfix, on trouve les options du Virtual Domains Control. C’est très utile pour utiliser plusieurs domaines sur votre serveur. Et toutes ces options farfouillent dans le service d’annuaire ldap. Donc quand Postfix appelle Procmail il transmet l’utilisateur et les droits reçus de l’annuaire ldap. Et donc pour la faire courte, les propriétaires des dossiers d’emails sont logiquement l’utilisateur vmail.

Mais, si on shunte ces options en mettant un domaine dans mydestination, les droits d’accès ne viennent plus de l’annuaire ldap mais des comptes sur le serveur. Dans ce cas Procmail dit “ça va pas du tout, les dossiers n’ont pas les bons droits d’accès et je vais renommer tout ça en BOGUS”.

Bref, en enlevant les domaines du paramètre mydestination dans le fichier main.cf de Postfix, tout va rentrer dans l’ordre (il faut laisser mydestination = localhost). Après avoir remis de l’ordre dans les dossiers BOGUS, on redémarre Postfix et Dovecot.