re-bonjour,
Par rapport à mon problème concernant la gestion des bounce qui ne
fonctionne pas,
-> J'ai un nouvel élément, si je regarde les logs de sympa, en
fait,
Feb 16 14:46:46 sympa01 bounced[1558]: List::new() Incorrect name:
listname "cri-test-owner" matches one of service aliases
Feb 16 14:46:46 sympa01 bounced[1558]: Skipping bouncefile
adresse@cachée for unknown list
adresse@cachée
il semblerait que le daemon de gestion des bounces ne veuille pas
du DSN. l'alias cri-test-owner est bien présent dans /etc/aliases.
Merci par avance de l'aide,
Christophe.
Le 16/02/2015 12:09, Christophe DUMONET a écrit :
adresse@cachée">
Bonjour,
Je te remercie pour ces réponses.
Je vais suivre tes conseils et pour les quelques listes
concernées faire pointer <nomliste>-owner vers
<nomliste>-request .
Par contre, peux-tu me donner un coup de main car j'ai un souci
sur cette installation de sympa, en effet, la gestion des
bounces semblent ne pas fonctionner : je n'ai rien dans le menu
gestion des erreurs , toujours le message
ERREUR (reviewbouncing) - Aucun bounce
pour l'utilisateur
voici les quelques tests que j'ai effectué :
- j'écris sur la liste cri-test, dont un des users est hors
quota, génération d'un DSN par sympa, et envoi sur l'adresse
Return-Path cri-test-owner :
( comportement normal à priori)
Feb 16 10:27:17 sympa01 postfix/qmgr[5411]: 0B48FB0684: from=<adresse@cachée>,
size=32886, nrcpt=1 (queue active)
Feb 16 10:27:17 zcsproxymta01 zcsproxymta01 postfix/smtp[23690]:
00629C0C5: to=<adresse@cachée>,
relay=sympa01.ifma.fr[192.168.134.2]:25, delay=0.05,
delays=0.01/0.01/0/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok:
queued as 0B48FB0684)
Feb 16 10:27:17 sympa01 postfix/smtpd[20281]: disconnect from
zcsproxymta01.ifma.fr[192.168.134.1]
Feb 16 10:27:17 zcsproxymta01 zcsproxymta01 postfix/qmgr[6668]:
00629C0C5: removed
Feb 16 10:27:18 sympa01 postfix/pipe[20293]: 0B48FB0684: to=<adresse@cachée>,
relay=sympabounce, delay=1, delays=0.02/0/0/1, dsn=2.0.0,
status=sent (delivered via sympabounce service)
Feb 16 10:27:18 sympa01 postfix/qmgr[5411]: 0B48FB0684: removed
- Ensuite, ce traitement est bien pris en charge par la
bouncequeue , comme c'est décrit dans mon fichier /etc/alias :
cri-test: "| /usr/lib/sympa/bin/queue adresse@cachée"
cri-test-request: "| /usr/lib/sympa/bin/queue adresse@cachée"
cri-test-editor: "| /usr/lib/sympa/bin/queue adresse@cachée"
#cri-test-subscribe: "| /usr/lib/sympa/bin/queue adresse@cachée"
cri-test-unsubscribe: "| /usr/lib/sympa/bin/queue adresse@cachée"
cri-test-owner: "|
/usr/lib/sympa/bin/bouncequeue adresse@cachée"
- Par contre, je ne trouve rien dans le spool de queue
/var/spool/sympa/bounce ( chemin décrit dans sympa.conf)
Je ne suis pas un expert sympa, et je ne vois pas trop où je
peux investigué pour faire repartir cette gestion de bounce,
Merci pour ton aide,
Cordialement,
Christophe Dumonet.
Le 12/02/2015 17:31, David Verdin a écrit :
adresse@cachée">
Le 12/02/15 17:17, Christophe
DUMONET a écrit :
adresse@cachée">
Effectivement,je viens de faire le test, c'est le champ
Return-Path et pas Reply-To qui est utilisé dans le cas des
notifications over-quotas.
Dans ce cas, est-il possible de forcer le champ Return-Path
pour les listes concernées à l'adresse du sender et non du
owner ?
Non. Enfin, pas dans Sympa. Il est prévu que Sympa traite les
erreurs lui-même.
Cela dit, si tes utilisateurs veulent se palucher la gestion des
erreurs, alors tu peux changer les alias : tu fais pointer
<nomliste>-owner vers <nomliste>-request et voilà !
Mais ça risque de leur faire un paquet d'erreurs à gérer.
Note qu'il faudra aussi changer le fichier list_aliases.tt2 pour
que les nouvelles listes soient créées avec cette règle.
Ah... En fait ça répond pas à ton problème mais je laisse la
réponse pour info et pour la culture de la liste.
Pour ton problème précis... Je pense que tu aurais intérêt à
essayer les hooks de messagerie que Soji a ajouté dans la
version 6.2. C'est encore expérimental mais ça permet justement
de tripatouiller le message à certains moments de leur
traitement - pour l'instant seulement avant de l'envoyer.
Mais en 5.3.4, désolé, il n'y a rien de ce type.
Tu aurais intérêt à faire en sorte que les profs soient
propriétaires de la leurs listes et appliquer la solution que
j'ai proposée.
Le listmaster propriétaire de toutes les listes, c'est une
mauvaise pratique, en Sympa, parce que ça t'oblige à t'occuper
de la gestion quotidienne des listes (qui peut s'abonner, la
modération des messages, etc.). Plus le service prend de
l'importance, plus ça te monopolise. Si tu délègues aux profs la
gestion de leurs listes, tu te débarasses de tout ça et tu peux
travailler sur des choses plus intéressantes.
adresse@cachée">
Le contexte est le suivant : je gère des listes sympa dans
le contexte d'une école, je suis propriétaire de toutes les
listes pour les gérer, les enseignants écrivent à des
étudiants qui sont les abonnés de ces listes. Et les
enseignants doivent être au courant qu'un élève n'a pas reçu
le mail car il est over-quota. ( et actuellement, le mail
est envoyé au propriétaire de la liste, moi ;-) )
Normalement, non : il est envoyé à <nomlistes>-owner@...
C'est l'adresse utilisée par Sympa pour récupérer les bounces.
Normalement, tu ne dois jamais recevoir ces messages. Si c'est
le cas, tu a un souci dans les alas.
adresse@cachée">
Merci à toi,
Christophe.
Le 12/02/2015 16:24, David Verdin a écrit :
adresse@cachée">
Bonjour,
Tu as fait ce qu'il fallait.
La 5.3.4, ça ne date pas d'hier, mais je pense que ça
marchait. Tu as bien enregistré la config après la
modification (désolé mais on sait jamais) ?
Cela dit, ça ne résoudra pas le problème des over-quotas :
les DSN sreont de toutes façons envoyées à l'adresse de
Return-Path, pas du Reply-To.
Ce n'est d'ailleurs pas un problème, c'est une feature :
les DSN sont traités par Sympa.
Cela dit si, pour certaines listes, tu tiens à ce que la
délivrance des messages soit suivie, il faut que tu mettes
à jour vers Sympa 6.2, qui implémente le tracking. On peut
alors savoir si le message a été délivré, lu, etc.
Et si l'utilisateur demande un accusé de réception, il est
possible que cet accusé de réception soit demandé par
Sympa, qui regroupe tout ça dans une table.
Bonne journée,
David
Le 12/02/15 16:17, @ifma.fr a
écrit :
Bonjour,
Je cherche le moyen dans Sympa de forcer la présence du champ Reply-To avec la
valeur du sender dans les messages délivrés.
En effet, si l'expéditeur initial n'envoie pas ce champ facultatif avec son
client de messagerie, les messages relayés par mon serveur Sympa sont reçu
aussi sans champ Reply-To dans les headers.
En son absence, le champ Return-Path est utilisé (selon la RFC822), et celui-
ci contient l'adresse du owner de la liste. ( gestion des bounces etc...)
Le problème est que l'absence de ce champ pose souci par exemple dans le cas
d'une notification à l'expéditeur d'un cas de non délivrance quand l'un des
abonnés est over-quota : le message de non délivrance est retourné à l'owner
de la liste ( champ return-path en l'absence du champ reply-to).
C'est considéré comme un bounce finalement, et l'expéditeur n'est pas tenu au
courant, ce qu'on me demande.
Ce que j'ai essayé, et qui ne fonctionne pas :
Je suis allé dans la config d'une des listes, et la valeur "reply_to_header",
était réglée par défaut à sender, avec le paramètre "respect du champ
existant" à "respect".
J'ai essayé de le forcé, en selectionnant "forced" pour ce dernier paramètre
sans succès.
J'ai un sympa en 5.3.4, et derrière un zimbra v8.
Merci à vous,
Christophe Dumonet.
--
A bug in Sympa? Quick! To
the bug tracker!
|
David Verdin
Études et
projets applicatifs
|
Tél : +33 2 23 23 69
71
Fax : +33 2 23 23 71 21
www.renater.fr
|
RENATER
263 Avenue du Gal Leclerc
35042 Rennes Cedex
|
--
A bug in Sympa? Quick! To
the bug tracker!
|
David Verdin
Études et
projets applicatifs
|
Tél : +33 2 23 23 69 71
Fax : +33 2 23 23 71 21
www.renater.fr
|
RENATER
263 Avenue du Gal Leclerc
35042 Rennes Cedex
|
|
