Il y a beaucoup d'instructions sur la façon d'augmenter le serveur de messagerie sur un tas de postfix - amavisd-new - dovecot. Et la grande majorité d'entre eux se répètent presque mot pour mot, y compris les erreurs et les inexactitudes.
Il me semble ennuyeux de pousser les boutons sans réfléchir, j'ai donc décidé d'optimiser la configuration standard: que faire si je construis l'interaction de postfix et amavisd-new non pas via localhost, mais sur une socket unix?
En fait, tout n'est pas si simple, mais je l'ai fait! Instruction et patch sous la coupe.
Honnêtement, je n'aime généralement pas l'interaction via l'hôte local au sein de la même machine. Si vous souhaitez organiser l'échange de données entre deux applications, il est beaucoup plus correct, plus sûr et moins gourmand en ressources de le faire via un socket Unix sur le système de fichiers. De plus, vous pouvez ainsi organiser la protection (au moyen de droits sur le système de fichiers) même si elle est absente au niveau de l'application ou du protocole.
Ainsi, le chemin du courrier dans le groupe discuté ressemble à ceci:
Il s'avère que nous devons organiser deux connexions: lors du transfert vers le filtrage et lors du retour au MTA. Puisque le socket est créé par l'écouteur, dans le premier cas, il sera amavisd, et dans le second - postfix.
Commençons par le second, car il est plus simple et mieux décrit. Pour que postfix crée une socket d'écoute, il vous suffit de spécifier unix, pas inet, dans la deuxième colonne de master.cf (colonne de type). Dans ce cas, la première colonne définit le chemin et le nom de fichier du socket.
Comme les processus postfix fonctionnent en chroot (cela peut être désactivé pour un processus spécifique, mais cela n'en vaut pas la peine), vous devez créer un dossier dans le répertoire personnel de postfix: / var / spool / postfix. Il aura les deux sockets:
mkdir /var/spool/postfix/amavis chown amavis:postfix /var/spool/postfix/amavis chmod 770 /var/spool/postfix/amavis
Configuration bien et postfixée:
amavis/postfix-in unix y - y - - smtpd -o smtpd_client_restrictions=$local_clients_only -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions= -o smtpd_milters=
Les options spécifiques dépendent de votre réglage, c'est mon option.
Il y a deux problèmes:
- Le chemin sera relatif à / var / spool / postfix / private, qui est soumis à des autorisations très strictes.
- Je ne sais pas si cela est vrai sur toutes les distributions, mais sur Ubuntu à coup sûr. Il vaut mieux ne pas toucher aux droits sur le dossier (les sockets de tous les services postfix sont là), il vaut mieux juste créer un lien symbolique.
- En plus du socket, postfix crée également un fichier pid pour le processus, dont le nom est généré automatiquement par le masque de $ type. $ Name. Où type sera égal à unix et le nom est tiré de la première colonne de master.cf. Il s'avère unux.amavis / postfix-in i.e. fichier dans un sous-dossier. Lui-même ne le créera pas et tombera avec une erreur.
Donc, nous substituons des béquilles:
cd /var/spool/postfix/private ln -s ../amavis . mkdir /var/spool/postfix/pid/unix.amavis
Pas très agréable, mais pas destructif pour la structure de dossiers régulière du package.
Nous redémarrons postfix et nous assurons que le fichier socket apparaît dans le dossier amavis et le fichier pid dans pid / unix.amavis. Malheureusement, les droits sur le socket sont 666, mais les droits sur le dossier que vous avez créé précédemment protégeront le fichier des regards inutiles.
Vous pouvez vérifier le travail avec la commande:
netcat -U /var/spool/postfix/amavis/postfix-in 220 mail.example.ru ESMTP Postfix
Eh bien, ils l'ont fait. Maintenant à amavisd.
Tout d'abord, configurez le chemin de retour du courrier via le socket unix appartenant à postfix. Cela fonctionne hors de la boîte:
$forward_method = 'smtp:/var/spool/postfix/amavis/postfix-in'; $notify_method = \$forward_method;
Eh bien, maintenant, la partie la plus difficile est de configurer des sockets dans amavisd. La solution peut être trouvée sur
Internet , mais là, il est proposé d'utiliser un seul socket spécifié par le paramètre $ unix_socketname. Je voulais aussi mon propre nouveau protocole amavisd (AM.PDP) et la réception du courrier via des sockets.
Le fichier de configuration par défaut contient une référence à la directive @listen_sockets, mais il n'y a aucune description pour cela. Mais c'est dans les
notes de version , même avec des exemples! Certes, il n'y a qu'une seule prise, mais qu'est-ce qui vous empêche d'essayer?
OK, mais comment définir le protocole pour le socket (qui est spécifié dans la banque de règles)? Dans tous les exemples, ils écrivent simplement SOCK. Par analogie avec les sockets inet (vous pouvez spécifier le port hôte ici), j'ai suggéré que vous deviez spécifier le chemin complet du fichier socket. Voici ce qui s'est passé:
$unix_socketname = undef; $inet_socket_bind = undef; $inet_socket_port = undef; @listen_sockets = ('/var/lib/amavis/amavisd.sock', '/var/spool/postfix/amavis/amavis-in.sock'); $unix_socket_mode = 0660; %interface_policy = ( '/var/lib/amavis/amavisd.sock' => 'AM.PDP-SOCK', '/var/spool/postfix/amavis/amavis-in.sock' => 'LMTP-SOCK' ); $policy_bank{'LMTP-SOCK'} = { protocol => 'LMTP' }; $policy_bank{'AM.PDP-SOCK'} = { protocol => 'AM.PDP', auth_required_release => 0,
Redémarrage, vérification - en effet, les deux sockets ont été créées! Victoire Pas vraiment, lorsque vous essayez de vous connecter au socket, rien ne se passe et une erreur est écrite dans le journal que le protocole n'est pas défini pour cela. Il s'avère que la banque de polices ne s'applique pas à eux.
Comment ça? Je devais aller au code.
Cette campagne a apporté deux nouvelles - comme d'habitude, bonnes et mauvaises. La bonne est que l'hypothèse concernant% interface_policy était correcte:
La mauvaise chose est que $ unix_socket_path entre dans cette fonction vide. Il est rempli comme suit:
my $is_ux = $sock && $sock->UNIVERSAL::can('NS_proto') && $sock->NS_proto eq 'UNIX';
Et les deux propriétés y sont vides.
Une étude de la
documentation a suggéré cette option:
my $unix_socket_path = $sock->hostpath();
Et ça a marché! Ready .patch peut être dit
ici .
Il y a la touche finale. Depuis amavisd crée sa propre socket avec des droits uniquement sur lui-même, et nous avons refusé l'accès au reste (ce qui est vrai), nous devons ajouter le suffixe au groupe amavis afin qu'il puisse écrire dans la socket:
gpasswd -a postfix amavis
C'est fait.
PS: J'ai envoyé le patch et la description du problème par Mark Martinec par mail car je n'ai trouvé aucune mention du bug tracker sur le
site . Je n'ai toujours pas reçu de réponse, mais je n'y compte pas vraiment - le projet semble abandonné (la dernière version il y a plus de deux ans).