Accéder au contenu.
Menu Sympa

fr - Re: [sympa-fr] Pb de regroupement des mails par sympa : nrcpt (à moitié) ignoré

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
  • Cc: pole hebergement <adresse@cachée>
  • Subject: Re: [sympa-fr] Pb de regroupement des mails par sympa : nrcpt (à moitié) ignoré
  • Date: Sun, 02 Nov 2014 00:08:01 +0100

Bonsoir,

Un spécialiste du VERP peut il nous éclairer sur l'hypothèse suivante : notre liste ayant provoqué une masse d'erreur au début, avant le réglage des domaines correspondants, nous avons incrémenté le compteur d'erreur d'une grande partie de nos abonnés. Pas énormément, mais suffisamment pour avoir au moins un abonné avec une erreur dans chaque paquet construit pour la table bulkmailer_table ; le paramètre merge_bulkmailer passe à 1 et l'envoi par sendmail est sectionné en envois individuels.

1/ Cet attribut a une valeur distincte entre la plateforme de prod (qui est incapable de grouper dest dans les sessions smtp) et la plateforme de test (qui y arrive). Pourtant, au vu du nom de l'attribut, j'aurais plutôt parié que le merge_bulkmailer autorisait la fusion des dest en une seule sesssion. Comment sont utilisés ces deux attributs (verp_bulkmailer et merge_bulkmailer) ?
2/ Si c'est bien la nécessité de créer une enveloppe verp qui pose le pb, comment remettre massivement les compteurs à 0 ?
3/ Comment est identifiée l'enveloppe verp dans la source des courriers reçus , Est elle préparée pour le lot entier ou juste pour le dest à pb ? Car dans ce que j'ai reçu personnellement, je ne trouve rien qui ressemble à un List_verp=xxx

Si ce n'est pas verp le coupable, je donne ma langue au chat... et il ne restera plus que sendmail lui même à qui faire porter le chapeau !

Cordialement

Le 31/10/2014 15:29, Luc Veillon a écrit :
Bonjour,

Nous rencontrons sur notre plate-forme nationale un problème gênant : les envois qui sont effectués dans le cadre de grosses listes (plusieurs centaines de milliers d'abonnés) sont préparés par sympa dans les tables bulkmailer_table et bulkspool_table en tenant compte du paramètre nrcpt =25 de notre sympa.conf :

mysql> select count(*) from bulkmailer_table where messageid_bulkmailer = "<5452305C.3090604@XXX>";

+----------+

| count(*) |

+----------+

| 36669 |

+----------+


Ce message-id est en attente d'envoi, sur une liste de 919664 abonnés, soit 36669*25=916725 adresses environ, ce qui est conforme.


Les paquets sont triés par domaine. Ex :
receipients_bulkmailer    verp_bulkmailer    merge_bulkmailer
adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée,adresse@cachée    0    1

Et pourtant, postfix ne recevra que des injonctions de postage pour 1 adresse/mailid :
Oct 31 04:17:07 postfix.sympa/qmgr[8665]: 15DB56592A: from=<adresse@cachée>, size=571953, nrcpt=1 (queue active)
Oct 31 04:17:07 postfix.sympa/qmgr[8665]: C487462ACF: from=<adresse@cachée>, size=571297, nrcpt=1 (queue active)
Oct 31 04:17:07 postfix.sympa/qmgr[8665]: C67E064C04: from=<adresse@cachée>, size=571953, nrcpt=1 (queue active)
Oct 31 04:17:07 postfix.sympa/qmgr[8665]: C98E66044B: from=<adresse@cachée>, size=571297, nrcpt=1 (queue active)

(aucun nrcpt différent de 1)
Sur une portion de log, l'examen des échanges postfix sur ce mailid donne :
message-id;mailid;to;start;end
54526C77.4090704@XXX;182399;182402;31/10/2014 03:49:14;31/10/2014 10:57:55

Soit, à trois unités près, autant de destinataires (182402) que de mailid (182399)

Les listes sont stockées par include file dans un base mysql.
Nous avons mis une temporisation ttl et de rafraichissement sur envoi de mail de 90 jours pour éviter des recharges pénalisant nos envois actuels.

Nous avons mis un postfix en face.

Version de sympa : 6.1.4 avec List.pm corrigé manuellement pour le § ci-dessous :
	[7309] src/lib/List.pm: [Submitted by O. Lacroix, CIRIL] When using a
	MySQL backend, sorting addresse by domain wouls not work due to double
	quotes in the SQL query around the keyword "dom". This lead to a bad
	usage of the nrcpt parameter. Fixed by removing the double quotes.

6.1.9		March 21, 2012

Je pensais trouver d'autres correctifs liés au nrcpt, mais le release-notes n'en fait pas mention.

Dernier point : pour une petite liste de 8 abonnés appartenant tous au même domaine, l'envoi est bien traité avec un nrcpt de 8 :
Oct 30 10:50:28 opmnsr21s postfix.sympa/qmgr[8665]: 8CE2760014: from=<adresse@cachée>, size=5894, nrcpt=8 (queue active)

Oct 30 10:50:28 postfix.sympa/qmgr[8665]: 8CE2760014: from=<adresse@cachée>, size=5894, nrcpt=8 (queue active)
Oct 30 10:50:28 postfix.sympa/smtp[15169]: 8CE2760014: to=<adresse@cachée>, relay=aspamdu.adc.education.fr[193.50.191.25]:25, delay=0.42, delays=0.33/0.04/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C8EF3420075)
Oct 30 10:50:28 postfix.sympa/smtp[15169]: 8CE2760014: to=<adresse@cachée>, relay=aspamdu.adc.education.fr[193.50.191.25]:25, delay=0.42, delays=0.33/0.04/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C8EF3420075)
Oct 30 10:50:28 postfix.sympa/smtp[15169]: 8CE2760014: to=<adresse@cachée>, relay=aspamdu.adc.education.fr[193.50.191.25]:25, delay=0.42, delays=0.33/0.04/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C8EF3420075)
Oct 30 10:50:28 postfix.sympa/smtp[15169]: 8CE2760014: to=<adresse@cachée>, relay=aspamdu.adc.education.fr[193.50.191.25]:25, delay=0.42, delays=0.33/0.04/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C8EF3420075)
Oct 30 10:50:28 postfix.sympa/smtp[15169]: 8CE2760014: to=<adresse@cachée>, relay=aspamdu.adc.education.fr[193.50.191.25]:25, delay=0.42, delays=0.33/0.04/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C8EF3420075)
Oct 30 10:50:28 postfix.sympa/smtp[15169]: 8CE2760014: to=<adresse@cachée>, relay=aspamdu.adc.education.fr[193.50.191.25]:25, delay=0.42, delays=0.33/0.04/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C8EF3420075)
Oct 30 10:50:28 postfix.sympa/smtp[15169]: 8CE2760014: to=<adresse@cachée>, relay=aspamdu.adc.education.fr[193.50.191.25]:25, delay=0.42, delays=0.33/0.04/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C8EF3420075)
Oct 30 10:50:28 postfix.sympa/smtp[15169]: 8CE2760014: to=<adresse@cachée>, relay=aspamdu.adc.education.fr[193.50.191.25]:25, delay=0.42, delays=0.33/0.04/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C8EF3420075)
Oct 30 10:50:28 postfix.sympa/qmgr[8665]: 8CE2760014: removed

=> avez vous rencontré ce pb ?
=> y a t-il un paramétrage qui m'échappe ?
=> une fois les lots préparés pour le bulk.pl, qui peut interférer pour empêcher que le lot complet soit traité en un seul appel ?

Cordialement
-- 
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


-- 
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




Archives gérées par MHonArc 2.6.19+.

Haut de le page