exim+spamassassin: spamcheck transport output

Le
François Boisson
Bonjour à tous,

un problème un peu compliqué que je n'arrive pas à résoudre.

Sur une debian sarge avec un Spamassassin de volatil puis un backport
de spamassassin de Etch:

J'ai des mails qui se perdent avec des erreurs notées:

2007-03-10 06:47:34 unexpected EOF while reading SMTP data (header)
from mail
2007-03-10 06:47:34 1HPuLd-0003hL-00 <user.anti-spam@met>:
spamcheck transport output: An error was detected while processing a
file of BSMTP input.
2007-03-10 06:47:34 1HPuLd-0003hL-00 <user.anti-spam@met>:
D=spamcheck_director T=spamcheck: Child process of spamcheck transport
returned 2 from command: /usr/sbin/exim

Les messages d'erreurs renvoyés à l'expediteur par exim sont comme suit:
********
Child process of spamcheck transport returned 2 from command:
/usr/sbin/exim
An error was detected while processing a file of BSMTP input.
The error message was:

554 Unexpected end of file

The SMTP transaction started in line 0.
The error was detected in line 3.
0 previous messages were successfully processed.
The rest of the batch was abandoned.
554 Unexpected end of file
Transaction started in line 0
Error detected in line 3

This is a copy of the message, including all the headers.

Return-path: <root@mon.domaine>
Received: from expourri.rebelles ([192.168.1.247]
helo=localhost.localdomain) by alf94-3-82-66-248-156.fbx.proxad.net
with esmtp (Exim 3.35 #1 (Debian)) id 1HPx8M-0004Rb-00
for <francois@mon.domaine>; Sat, 10 Mar 2007 09:40:58 +0100
Received: from root by localhost.localdomain with local (Exim 4.50)
id 1HPx8S-00017N-HT
for root@localhost.localdomain; Sat, 10 Mar 2007 09:41:04 +0100
From: Anacron <root@mon.domaine>
To: root@localhost.localdomain
Subject: Anacron job 'cron.daily' on expourri
Message-Id: <E1HPx8S-00017N-HT@localhost.localdomain>
Date: Sat, 10 Mar 2007 09:41:04 +0100
X-Scanner: exiscan *1HPx8M-0004Rb-00*.xZ5GWDNhaM*

/etc/cron.daily/lprng:
*****************

J'ai mis le message complet car je ne comprends pas ce qu'est cette
fameuse ligne 3.

La directive exim (exim 3 de sarge) est la suivante:

spamcheck:
driver = pipe
command = /usr/sbin/exim -oMr spam-scanned -bS
transport_filter = /usr/bin/spamc -p 780
bsmtp = all

J'ai essayé de remplacer cela par

spamcheck:
driver = pipe
command = /usr/bin/spamc -p 780 -e /usr/sbin/exim -oMr
spam-scanned -bS
(une seule ligne) suivant les idées du seul message un peu précis
trouvé sur Google à ce sujet (à savoir
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20060206/msg00196.html
)

mais cela m'a donné une erreur du même type disant

********
[..]
an error was detected while processing a file of BSMTP input.
The error message was:

500 Command unrecognized

The SMTP transaction started in line 0.
The error was detected in line 1.
The SMTP command at fault was:

X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on

0 previous messages were successfully processed.
The rest of the batch was abandoned.
500 Command unrecognized
Transaction started in line 0
Error detected in line 1
[..]
***************

erreur que je ne comprends pas, exim devrait prendre la sortie directe
et la traiter. Or il semble prendre l'entrée comme un fichier de
commandes.

Bref, je patauges un peu. Si les courageux (que je remercie) qui ont lu
ce message jusque là (et qui vont le terminer, le plus dur est fait!)
ont une idée, je suis preneur. En attendant, comme il semble que ça
*serait* un problème de timeout, j'ai rajouté une option -t 300 à
l'appel de spamc.

Le pbm est que je n'ai pas une idée clair de ces directives (entre
autres bsmtp=all fait quoi?)

Merci de toutes réponses

François Boisson


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
François Boisson
Le #9529751
> J'ai essayé de remplacer cela par

spamcheck:
driver = pipe
command = /usr/bin/spamc -p 780 -e /usr/sbin/exim -oMr
spam-scanned -bS
(une seule ligne) suivant les idées du seul message un peu précis
trouvé sur Google à ce sujet (à savoir
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20060206/msg00196.html
)



Bon, après essais successifs, ce serait plutôt

/usr/bin/spamc -p 780 -e /usr/sbin/exim -oMr
spam-scanned -bm -t

Avec cela il n'y a plus d'erreur, la directive bsmtp est une directive
donnant un format «batched smtp format» à la sortie de spamc.

J'ignore si cette rustine va fonctionner et suis toujours intéressé par
des suggestions.

François Boisson


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
François Boisson
Le #9529731
> Bon, après essais successifs, ce serait plutôt

/usr/bin/spamc -p 780 -e /usr/sbin/exim -oMr
spam-scanned -bm -t




Marche pas lorsque l'adresse du destinataire n'est pas dans les entêtes
du message :(. Retour à la case départ.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
François Boisson
Le #9529471
Le Sat, 10 Mar 2007 17:53:47 +0100
François Boisson [..]

Suite pour ce qui suivent (merci à eux).

Le problème semblent précis: Pour des raisons encore floues, le démon
spamd gèle dans le traitement d'un message. Exim est assez impatient
dans le traitement d'un transport, si le retour n'a pas lieu vite, il
sort cette fameuse erreur 2.

Une rustine indispensable pour ne pas perdre du courier consiste à
donner à spamc un timeout serré de 60s (en gros le traitement d'un mail
prend 10s), cela se fait par la directive
command = /usr/sbin/exim -oMr spam-scanned -bS
transport_filter = /usr/bin/spamc -t 60 -p 780
(rajout du «-t 60»).

De même, il est raisonnable de lancer spamd avec une option
--timeout-childY
afin d'avoir un timeout de spamd.

Dans ces conditions, il n'y a plus de mails perdus. Par contre, lors du
déclenchemenbt du timeout, les maisl ne sont pas filtrés et les spams
passent.

Pour les raisons, j'ai noté dans les logs de spamssassin (spamd avec
-D) deux choses:

1)
auto-whitelist: open of auto-whitelist file failed: auto-whitelist:
cannot open auto_whitelist_path /var/mail/.spamassassin/auto-whitelist:
Ioctl() inappropré pour un périphérique

le path est bon, je ne comprends pas l'erreur. Bon, j'ai viré le
recours à la whitelist.

2) Des messages
bayes: expire_old_tokens: child processing timeout at /usr/sbin/spamd
line 1085.
qui semblent correspondre au moment du gel.

Dans le doute, j'ai donc refait complètement la base bayes. Celle ci
provenait d'une version de spamassassin 2.6?? converti par sa-learn.
Quelqu'un a-t-il eu des pbms dans des conditions similairees?


François Boisson


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
François Boisson
Le #9527461
Bon, cette fois c'est complètement résolu et ça n'est pas exim.

C'est le bug 4950 de spassassin
http://issues.apache.org/SpamAssassin/show_bug.cgi?idE90 que l'on
peut résoudre en mettant l'option «--round-robin» dans les options de
lancement de spamassassin. C'est en problème dans le fork des spamd
fils apparu avec la version sarge de spamassassin, les réglages

spamc appelé avec une option -t 60 et
spamd avec l'option --timeout-child`

m'ont permis de ne plus perdre de mails.
En trouvantun mail qui avait rencontrer le problème et l'heure précise
ou le pbm a commencé, j'ai pu comprendre mieux le pbm. Les logs ont
montré dans mail.info (et là seulement)


Mar 17 07:55:31 cerbere spamd[8747]: prefork: syswrite(6) to 7687
failed on try 4
at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 610.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: giving up
at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 612.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: write of ping failed to
7687 fd=6: at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm
line 343.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: killing failed child
7687 fd=6 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm
line 137.
Mar 17 07:55:31 cerbere spamd[8747]: spamd: handled cleanup
of child pid 7687 due to SIGCHLD Mar 17 07:55:31 cerbere spamd[8747]:
prefork: killed child 7687 Mar 17 07:55:31 cerbere spamd[8747]:
prefork: select returned -1! recovering: Mauvais descripteur de fichier
Mar 17 07:56:02 cerbere last message repeated 31 times Mar 17 07:56:32
cerbere last message repeated 30 times


Une recherche là dessus plus un épluchage des sources de
SpamdForkScaling.pm et une recherche sur fork dans le manuel de spamd
m'ont conduit à la solution. Celle ci est confirmé dans
http://www.drazzib.com/docs:mail:spamassassin (sans explication) Ouf!,
ça aura mis 15 jours...

François Boisson


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Patrice OLIVER
Le #9527301
Merci François pour cette information qui sera prévieuse à ceux
d'entre nous dont je fais partie qui utilisent spamassassin.

Bonne journée.
:)

Patrice.

Le 18/03/07, François Boisson
Bon, cette fois c'est complètement résolu et ça n'est pas exim.

C'est le bug 4950 de spassassin
http://issues.apache.org/SpamAssassin/show_bug.cgi?idE90 que l'on
peut résoudre en mettant l'option «--round-robin» dans les options de
lancement de spamassassin. C'est en problème dans le fork des spamd
fils apparu avec la version sarge de spamassassin, les réglages

spamc appelé avec une option -t 60 et
spamd avec l'option --timeout-child`

m'ont permis de ne plus perdre de mails.
En trouvantun mail qui avait rencontrer le problème et l'heure précis e
ou le pbm a commencé, j'ai pu comprendre mieux le pbm. Les logs ont
montré dans mail.info (et là seulement)


Mar 17 07:55:31 cerbere spamd[8747]: prefork: syswrite(6) to 7687
failed on try 4
at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 610.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: giving up
at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm line 612.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: write of ping failed to
7687 fd=6: at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm
line 343.
Mar 17 07:55:31 cerbere spamd[8747]: prefork: killing failed child
7687 fd=6 at /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm
line 137.
Mar 17 07:55:31 cerbere spamd[8747]: spamd: handled cleanup
of child pid 7687 due to SIGCHLD Mar 17 07:55:31 cerbere spamd[8747]:
prefork: killed child 7687 Mar 17 07:55:31 cerbere spamd[8747]:
prefork: select returned -1! recovering: Mauvais descripteur de fichier
Mar 17 07:56:02 cerbere last message repeated 31 times Mar 17 07:56:32
cerbere last message repeated 30 times


Une recherche là dessus plus un épluchage des sources de
SpamdForkScaling.pm et une recherche sur fork dans le manuel de spamd
m'ont conduit à la solution. Celle ci est confirmé dans
http://www.drazzib.com/docs:mail:spamassassin (sans explication) Ouf!,
ça aura mis 15 jours...

François Boisson


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact .org




François Boisson
Le #9525161
Je pensais avoir trouvé la raison du problème, eh ben non. Ce matin,
gel des trois démons spamd (mais aucun message perdu). La version 3.1.7
semble être prémunie contre ce bug 4950). Bon, suite des investigations.
Test sur des messages ayant gelé spamassassin, je constate que ces
messages passent très bien. Cela veut dire que le gel est indépendant
des messages. Peut être que cela vient de la grosseur de la base de
données, cela expliquerait que après chacune de mes interventions tout
se passe bien.

Fort de ces réflexions, je me rappelle de la fonction force-expire de
sal-learn, regardes les options de spamassassin et constate qu'il y a
une fonction auto_expire. Un recherche sur les news avec cette fonction
montre qu'elle entraine un grand délai de spamd avec également une
boucle infernale possible sur le verrouillage de la base bayes. Je
teste donc une nouvelle configuration qui supprime l'auto-expire et je
rajoute dans le crontab, juste après le sa-learn --sync quotidien un
sa-learn --force-expire. Si ma théorie est juste, cela devrait
enfin résoudre mon problème. En conclusion:

* spamc appelé avec une option -t 60
* spamd avec l'option --create-prefs --timeout-child`
--max-children 3 -c --helper-home-dir
* Rajout de l'option bayes_auto_expire 0 dans local.cf
use_bayes 1
bayes_auto_learn 1
bayes_auto_expire 0
* Appel quotidien de sa-learn --force-expire


Ce coup là, ça devrait être bon :)

François Boisson


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme