Accéder au contenu.
Menu Sympa

fr - Re: [sympa-fr] Problème traitement des bounce

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: Luc Veillon <adresse@cachée>
  • To: adresse@cachée
  • Subject: Re: [sympa-fr] Problème traitement des bounce
  • Date: Thu, 9 Jun 2016 10:06:30 +0200

Bonjour,

Voici la solution à laquelle nous sommes parvenus et qui fonctionne depuis quelques jours.

Rappel : le traitement en réception des retours de bounce en mode VERP nécessite l'usage de wildcard car les libellés complets ne sont pas prédictibles et ne peuvent être saisis par avance dans le fichiers des alias que sympa saisit pour postfix.  Or l'usage du wildcard est incompatible avec un traitement de type "local" pour des raisons de sécurité. Il faut donc intercepter en amont l'adresse, l'interpréter avec une regexp, avant de la renvoyer sur un traitement local de type "pipe" sur le programme bouncequeue.  Une solution possible : utiliser un domaine fictif pour forcer au passage l'utilisation de la regexp dans le cadre d'un processus de transport

Les messages vont suivre le synoptique suivant :

- adresse@cachée émet un mail sur la liste adresse@cachée
- postfix traite l'adresse par virtual_regexp et transforme le mail en adresse@cachée
- aucun pattern correspondant à cette adresse n'existe dans les données mentionnées dans alias_maps (dont le fichier d'alias tenu à jour par sympa),  postfix passe alors à la table transport  et utilise la regexp  : /^.*\@vlist2.lan$/ sympavlist:
- postfix transmet le mail ( via la ligne de configuration définit dans le master.cf) dans la queue de sympa et le force avec le nom de robot véritable : vlist.education.gouv.fr => /appli/sympa/sympaV6.2.12/sympa/bin/queue adresse@cachée
- sympa envoi le mail aux destinataires, un abonné revient en erreur ( adresse@cachée ) depuis smtp-out-02 : adresse@cachée>
- postfix transforme le mail en erreur via le virtual_regexp  : adresse@cachée>
- postfix transmet le mail grâce au transport_regexp à la file sympa : sympabouncevlist , donc : /appli/sympa/sympaV6.2.12/sympa/bin/bouncequeue adresse@cachée
- le mail bounce est traité.
Configuration correspondante : virtual_regexp :

/^(.*)@vlist\.education\.gouv\.fr$/ $adresse@cachée

Transport_regexp :

/^bounce+.*\@vlist2.lan$/ sympabouncevlist:
/^.*-owner\@vlist2.lan$/ sympabouncevlist:
/^.*\@vlist2.lan$/ sympavlist:

Master.cf

sympavlist unix - n n - - pipe flags=R user=sympa argv=/appli/sympa/sympaV6.2.12/sympa/bin/queue ${adresse@cachée
sympabouncevlist unix - n n - - pipe flags=R user=sympa
argv=/appli/sympa/sympaV6.2.12/sympa/bin/bouncequeue ${adresse@cachée

Main.cf

sympa_destination_recipient_limit = 1
sympabounce_destination_recipient_limit = 1

 ! Cette configuration ne prend plus en compte le fichier d'alias rempli automatiquement par Sympa. Il ne faut donc plus prendre en compte l'ajout/suppression d'alias dans ce fichier. ( hors vérification fonctionnement normal de sympa )

Cordialement

Le 31/05/2016 à 10:46, Thibaut Jacob (via sympa-fr Mailing List) a écrit :

Merci pour vos réponses.

Par contre du coup, j'ai un problème de compréhension sur la structure que doit alors avoir le fichier sympa.aliases afin qu'il prenne en compte les expressions régulières tout en gardant les alias sympa intact. ( Sachant que les alias son créer directement par sympa lors d'un création de liste.

J'ai effectué un nouveau test suite à l'architecture mise en place dans l'ancienne configuration du type :

virtual_regexp :
/^(.*)-owner\@(.*)$/    $1+owner@$2

transport_regexp :
/^bounce+.*\@eil.*$/                                 sympabounceeil:
/^.*\+owner\@eil/                                    sympabounceeil:
/^.*\@eil\.syndicat\.education\.gouv\.fr$/                           sympaeil:

master.cf :
# Sympa
sympaeil              unix  - n       n       -       -       pipe flags=R user=sympa argv=/appli/sympa/sympaV6.2.12/sympa/bin/queue ${recipient}
sympabounceeil    unix  - n       n       -       -       pipe flags=R user=sympa argv=/appli/sympa/sympaV6.2.12/sympa/bin/bouncequeue ${user}@${nexthop}

sans succès, l'erreur reste présente :

postfix/cleanup[10658]: 2635780002: message-id=<adresse@cachée>
postfix/qmgr[10224]: 2635780002: from=<adresse@cachée>, size=1546, nrcpt=1 (queue active)
postfix/pickup[10223]: 6D98980003: uid=500 from=<adresse@cachée>
postfix/cleanup[10658]: 6D98980003: message-id=<adresse@cachée>
postfix/qmgr[10224]: 6D98980003: from=<adresse@cachée>, size=1546, nrcpt=1 (queue active)
postfix/smtp[10661]: 2635780002: to=<adresse@cachée>, relay=mx1.ac-orleans-tours.fr[195.83.89.173]:25, delay=0.65, delays=0.29/0.02/0.27/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 74E5F98108)
postfix/qmgr[10224]: 2635780002: removed
postfix/smtp[10663]: 6D98980003: to=<adresse@cachée>, relay=mx2.ac-orleans-tours.fr[195.83.89.174]:25, delay=0.44, delays=0.3/0.01/0.07/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 85A6150097)
postfix/qmgr[10224]: 6D98980003: removed
postfix/pickup[10223]: BAFBA80002: uid=500 from=<adresse@cachée>
postfix/cleanup[10658]: BAFBA80002: message-id=<adresse@cachée>
postfix/qmgr[10224]: BAFBA80002: from=<adresse@cachée>, size=801, nrcpt=1 (queue active)
postfix/smtp[10661]: BAFBA80002: to=<adresse@cachée>, relay=mx2.ac-orleans-tours.fr[195.83.89.174]:25, delay=0.43, delays=0.3/0/0.06/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as CF205500A5)
postfix/qmgr[10224]: BAFBA80002: removed
postfix/smtpd[10521]: connect from pr-sti-mtamx02.tec.in.phm.education.gouv.fr[172.29.68.194]
postfix/smtpd[10521]: NOQUEUE: reject: RCPT from pr-sti-mtamx02.tec.in.phm.education.gouv.fr[172.29.68.194]: 550 5.1.1 <adresse@cachée>: Recipient address rejected: User unknown in local recipient table; from=<> to=<adresse@cachée> proto=ESMTP helo=<mx02.phm.education.gouv.fr>

Cordialement,


Le 31/05/2016 à 09:02, Raoul Kuczyk a écrit :
Pareil.

Bonne journée à tous.
Raoul K.

On 30/05/2016 19:23, Guillaume Tournat wrote:
il me semblait qu'une table compilée de type hash ne supportait pas les expressions régulières.
à la différence d'une table évaluée de type regexp...


-- 
Thibaut JACOB
Pôle Hébergement National
Ingénieur d'étude
DSI - Rectorat d'Orléans-Tours
02 38 79 45 04

-- 
Luc VEILLON
Pôle IH2M Equipe "Hub - Hébergement - Messagerie"
DSI - Rectorat d'Orléans-Tours
10 Rue Molière
45 000 Orléans
Tél: 02 38 79 45 20/ 02 38 79 45 51
Fax: 02 38 79 45 29
Mel : adresse@cachée



  • Re: [sympa-fr] Problème traitement des bounce, Luc Veillon, 09/06/2016

Archives gérées par MHonArc 2.6.19+.

Haut de le page