[30926] warn: rules: failed to run CG_FUJI_JPG test, skipping:
[30926] warn: (Can’t locate object method « image_name_regex » via package « Mail::SpamAssassin::PerMsgStatus » at (eval 1466) line 856.
[30926] warn: )
[30926] warn: rules: failed to run CG_DOUBLEDOT_GIF test, skipping:
[30926] warn: (Can’t locate object method « image_name_regex » via package « Mail::SpamAssassin::PerMsgStatus » at (eval 1466) line 986.
[30926] warn: )
[30926] warn: rules: failed to run CG_SONY_JPG test, skipping:
[30926] warn: (Can’t locate object method « image_name_regex » via package « Mail::SpamAssassin::PerMsgStatus » at (eval 1466) line 1602.
[30926] warn: )
[30926] warn: rules: failed to run CG_CANON_JPG test, skipping:
[30926] warn: (Can’t locate object method « image_name_regex » via package « Mail::SpamAssassin::PerMsgStatus » at (eval 1466) line 2704.
[30926] warn: )

Je commente l’appel à ces règles dans /etc/spamassassin/imageinfo.cf.
Et enfin je désactive la mise à jour via sa-update, en commentant mes lignes /etc/spamassassin/channels.txt.

A suivre.

Pour ceux qui n’utiliseraient pas encore de greylisting pour limiter le nombre de spams en entrée de ses serveurs de mails, j’explique comment mettre en place dans ma doc Debian et dans plusieurs articles sur ce blog.

Voici donc une capture d’un échange dans /var/log/mail.[info|log] d’un serveur envoyant un mail à cette architecture postfix/postgrey. Vous pouvez l’imprimer et l’afficher au-dessus de votre lit, c’est joli.

Rappel de la théorie

Le greylisting demande à l’émetteur de renvoyer le mail plus tard, disons 5 minutes. C’est un comportement normal et possible d’un serveur SMTP. Si l’expéditeur est complètement bidon (un zombie par exemple), cette réponse n’arrive jamais. Le mail – qui est un spam ou venant d’un serveur configuré avec les pieds – ne reviendra jamais et n’ira donc pas plus loin que la porte d’entrée du serveur. Pas de traitement anti-spam, rien. Economie de charge CPU etc.
Au bout de quelques mails effectivement reçus de la part de tel serveur, alors on le whiteliste car il semble au moins digne de confiance (je n’ai pas dit qu’il n’envoyait pas du spam). Attention au délai de réception pendant une journée ou 2.

Let’s go

Prise de contact

Aug 27 15:51:05 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:51:06 mon_srv postgrey[12790]: action=greylist, reason=new, client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:51:06 mon_srv postgrey[12790]: cleaning up old logs...
Aug 27 15:51:06 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:51:06 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

On voit l’action de postgrey (action=greylist) au motif que ce serveur n’a pas encore été whitelisté (reason=new)
Avant dernière ligne : on informe le serveur expéditeur qu’il est greylisté, on en profite pour expliquer à l’admin d’en face qui (peut-être) lit les logs ce qu’est le greylisting.
Sous-entendu, on lui dit via le code retour 450 que la boite a un problème temporaire, sous-entendu, retente plus tard. Attention, on ne dit pas code 550 qui signifierait « la boite est morte définitivement ».

Maintenant on attend de voir s’il nous recontacte

Il revient, mais trop tôt

Une minute plus tard, on a :

Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:52:06 mon_srv postgrey[12790]: action=greylist, reason=early-retry (239s missing), client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

L’action est de le greylister à nouveau au motif qu’il est trop tôt (reason=early-retry (239s missing)). Le temps doit être donné dans la réponse d’indisponibilité temporaire mais ça ne se voit pas au niveau des logs).
Et on le renvoit dans ses pénates.
Le revoilà, mais encore trop tôt.< méchanceté gratuite>C’est un serveur Exchange, il ne doit rien comprendre à ce qu’on dit< /méchanceté gratuite>.

Aug 27 15:53:06 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:53:08 mon_srv postgrey[12790]: action=greylist, reason=early-retry (177s missing), client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:53:08 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:53:08 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

̉Trop c’est trop : anvil

Maintenant, c’est simplement le processus « anvil » de postfix, le « contrôleur de nombre de sessions et taux de bourrinage » qui détecte que le serveur en face est un peu trop insistant (il vient trop souvent) :

Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max connection rate 1/60s for (smtp:10.20.30.40) at Aug 27 15:51:05
Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max connection count 1 for (smtp:10.20.30.40) at Aug 27 15:51:05
Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max cache size 1 at Aug 27 15:51:05

On ferme carrément la connexion. Reviens plus tard on te dit.

Là il est calmé

Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 16:03:09 mon_srv postgrey[12790]: action=pass, reason=triplet found, delay=724, client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr

J’accepte son mail comme on voit ci-dessous (action=pass) au motif qu’on l’a déjà bien embêté (reason=triplet found). Au final, il y a aura eu pour ce mail 724 secondes de délai. Rappelez-vous que ça peut être gênant lors d’une mise en place sur un serveur déjà en prod.

La suite est l’enchaînement logique postfix :

Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: 1E6B29C4057: client=le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 16:03:09 mon_srv postfix/cleanup[17164]: 1E6B29C4057: message-id=<8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>
Aug 27 16:03:09 mon_srv postfix/qmgr[15006]: 1E6B29C4057: from=, size=6905, nrcpt=1 (queue active)
Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

On arrive dans amavisd-new :

Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)run_av (ClamAV-clamd) FAILED - unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n"
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)ClamAV-clamd av-scanner FAILED: CODE(0x90a9148) unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n" at (eval 86) line 527.
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)WARN: all primary virus scanners failed, considering backups

Aaaaah, ça foire (normal j’ai juste installé clamav, il est détecté par amavis, mais je n’ai rien configuré. Je dois avoir un problème de droits/groupes, ce genre-là. On verra dans mon prochain article qui décrira toute la mise en place.

Aug 27 16:03:10 mon_srv postfix/smtpd[17169]: connect from localhost.localdomain[127.0.0.1]
Aug 27 16:03:10 mon_srv postfix/smtpd[17169]: C2A8D9C405B: client=localhost.localdomain[127.0.0.1]
Aug 27 16:03:10 mon_srv postfix/cleanup[17164]: C2A8D9C405B: message-id=<8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>
Aug 27 16:03:10 mon_srv postfix/qmgr[15006]: C2A8D9C405B: from=, size=7349, nrcpt=1 (queue active)
Aug 27 16:03:10 mon_srv amavis[17143]: (17143-01) Passed CLEAN, [10.20.30.40] [10.20.30.40]  -> , Message-ID: <8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>, mail_id: xmX0C24kDlYt, Hits: -, size: 6905, queued_as: C2A8D9C405B, 1764 ms
Aug 27 16:03:10 mon_srv postfix/smtp[17165]: 1E6B29C4057: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.11/0/0/1.8, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=17143-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as C2A8D9C405B)
Aug 27 16:03:10 mon_srv postfix/qmgr[15006]: 1E6B29C4057: removed

Ci-dessus on a le baratin standard d’un amavis sans clamav (avec son anti-virus interne) qui finit par accepter le mail et le délivrer.

Voilà, c’est beau, on dirait du Rimbaud.

Depuis quelques semaines (mois ?), le programme RulesDuJour végétait. Il n’y a eu aucune communication sur le sujet à part 2/3 infos éparses dans des mailing-lists. J’ai pris le temps de chercher et poser les questions.
Maintenant, je peux affirmer que RulesDuJour n’est plus supporté (mais fonctionne encore à peu près) et un type du projet spamassassin a monté un serveur permettant de mettre à jour les règles SARE depuis l’outil normal de mise à jour de spamassassin, à savoir sa-update.

Le principe pour configurer sa-update afin qu’il aille chercher vos règles SARE est le suivant :
1) Vous supprimez votre « RulesDuJour » quotidien de votre crontab.
2) Gardez quelque part la liste des règles que vous utilisez (noms des fichiers).
3) Supprimez les règles type /etc/spamassassin/7*cf et le répertoire où vous stockiez RulesDuJour.
4) Ensuite, créez un fichier /etc/spamassassin/channels.txt contenant :

updates.spamassassin.org
70_sare_adult.cf.sare.sa-update.dostech.net
70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
70_sare_evilnum0.cf.sare.sa-update.dostech.net
70_sare_evilnum1.cf.sare.sa-update.dostech.net
autre.regle.de.SARE.cf.sare.sa-update.dostech.net
...

et vos autres règles type blabla.cf en suffixant par .sare.sa-update.dostech.net. Vous comprenez le principe ? le serveur dostech s’attend à recevoir des demandes « au format sa-update » et grâce à des noms de machines bidons indiquant en fait le nom du fichier correspondant à la règle que vous cherchez, sa-update trouve son bonheur.
Ne pas oublier la 1ère ligne des updates « normaux » de spamassassin.

Ensuite, vous planifiez une fois par jour le job suivant :

sa-update --allowplugins --channelfile /etc/spamassassin/channels.txt --nogpg /usr/local/bin/sa-compile && /etc/init.d/spamassassin reload

Notez qu’il y a déjà dans votre /etc/cron.daily un update spamassassin. Faut-il le modifier ? bof, c’est de la conf standard, c’est un coup à ce que ça saute au prochain update/upgrade.
La deuxième partie de la commande (&& /etc/init.d/spamassassin reload) n’est utile que si votre spamassassin tourne en tant que « daemon ».

Les nouvelles règles téléchargées iront s’installer dans /var/lib/spamassassin/3.002003.

Astuce of ze day pour générer sans peine (et sans faute de frappe) le fichier channels.txt. En considérant que vos règles SARE actuelles sont dans /etc/spamassassin et se nomment toutes 7*cf, tapez donc ça :

cat updates.spamassassin.org > /etc/spamassassin/channels.txt
for i in 7*cf
do
echo $i.sare.sa-update.dostech.net >> /etc/spamassassin/channels.txt
done

Voilà. Forcez le premier lancement à la main et contrôlez le contenu du répertoire /var/lib/spamassassin/3.002003 et la présence du daemon spamassassin (si vous l’utilisez en « daemon »).

La « doc » qui fait foi est ici : http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt

Informations en préambule

Les impacts pour l’utilisateur sont minimes : délai d’environ 30 minutes (en théorie 5 minutes) lors des x (x = 5 par défaut) premiers échanges entrants avec un serveur donné. L’article anglais sur wikipedia se veut un peu plus méfiant que sa traduction minimaliste en français. A vous de voir. L’autre risque serait de se retrouver face à un vieux serveur de mails tout pourri qui implémente mal le protocole… boarf, je doute que ça arrive dans la pratique. Au pire l’utilisateur verra le problème et il sera temps de whitelister ledit serveur.

Principe

Le principe – je vous renvois à l’article wikipedia pour plus de détails – est d’utiliser une fonction standard du procotole SMTP pour redemander l’envoi d’un mail lorsqu’on le reçoit. On indique au serveur de renvoyer le message dans 5 minutes. Deux options : le serveur en face le fait, ou non. Au bout de x fois – si le serveur s’est bien comporté – on le « whiteliste » pour de bon et il n’y aura plus de délai pour celui-ci.

Quel lien avec les spammeurs ?

Imaginez une armée de PC (windows) zombies envoyant des mails à tout va (à l’insu de l’utilisateur, forcément). Le zombie utilise un programme le plus simple possible qui se contente d’envoyer la purée. De toute manière, un PC zombie comme de ce type n’a en général pas de lien retour possible vers lui même sur le port 25 (pensez à votre PC derrière un routeur genre freebox). Donc il ne recevra jamais votre demande standard de renvoi de mails. Et donc vous n’aurez jamais le mail, qui était un spam à coup sûr. CQFD.
Lisez plus bas dans l’article quelques extraits d’adresses « greylistées », vous comprendrez que des zombies, il y en a des millions sur la planète… que fait Buffy ???
Reste ensuite les *vrais* spammeurs. Je ne sais pas dire si beaucoup d’entre eux utilisent des serveurs standard de mails. Ceux qui n’ont pas prévu le coup en tout cas, ils passent aussi à la benne. Les autres, je ne sais pas s’ils perdent du temps à renvoyer la purée alors que des gens mal protégés, il y en a tant d’autres…
Alors, en attendant que les zombies prennent en charge correctement le protocole et fasse des contournements réseaux compliqués (impossible ?), le greylisting peut vous aider.

Léger pré-requis sur les backups MX

Dernière petite remarque en préambule : il faut que tous vos serveurs frontaux (donc les backups MX) implémentent le greylisting !!! Donc oubliez les backups gracieusement offerts par votre fournisseur/hébergeur etc. En général ils ne le font pas. Si vous avez un tel backup MX – par pseudo-sécurité – il est en général déclaré de faible priorité et c’est justement celui qui est d’abord visé par les envois de spammeurs car on n’a moins souvent la main dessus. S’il ne greyliste pas, alors il enverra tout à votre MX principal qui acceptera sans broncher. Le greylisting ne servira pas à grand chose dans ce cas.
(Tiens, ça me fait penser à une technique qui consiste à utiliser un serveur inexistant comme MX de plus faible priorité. Faudra que je teste ça un jour. Si quelqu’un a un retour, je suis preneur)

Graphiques après plusieurs semaines d’utilisation

Plutôt qu’un long discours, quelques dessins. Je vous laisse deviner la date de mise en place…

Sur le frontal (MX primaire) :

Et sur le backend (qui identifie les spams une fois le mail accepté) :

En chiffres

Avec quelques chiffres moyens pris avant et après le greylisting (ceux sur le graphe sont pris « pendant » la mise en place, donc une moyenne d’avant/après, pas terrible), ça donne ça :
- Sur le frontal, avant, on recevait environ 9,5 msg/min et on rejetait 1/3 (tentatives d’openrelay, destinataires bidon etc). Maintenant, on en reçoit 3,2 par minute, toujours 1/3 de rejet pour les mêmes motifs.
- Sur le backend du coup, il y a une sacrée chute d’occupation CPU par « spamd » et on identifie 0,6 msg/min contre 6 par minute avant (même taux de faux-positifs ou d’oubli, à savoir presque nul).
- En une semaine, ce ne sont pas moins de 137000 « serveurs » (zombies) qui ont été greylistés, avec des charmants noms comme :

         0x50a1511f.hknxx3.adsl-dhcp.tele.dk[80.161.81.31] 2 Time(s)
         0x50a403bf.abnxx10.adsl-dhcp.tele.dk[80.164.3.191] 2 Time(s)
         103.95.119-80.rev.gaoland.net[80.119.95.103] 4 Time(s)
         12-208-209-2.client.mchsi.com[12.208.209.2] 2 Time(s)
         12-219-39-94.client.mchsi.com[12.219.39.94] 2 Time(s)
         124-171-184-145.dyn.iinet.net.au[124.171.184.145] 2 Time(s)
         129-28-235-201.fibertel.com.ar[201.235.28.129] 2 Time(s)
         131.201.218.87.dynamic.jazztel.es[87.218.201.131] 2 Time(s)
         131.206.50.60.cbj04-home.tm.net.my[60.50.206.131] 2 Time(s)
         1434933186.ip2long.net[85.135.87.194] 2 Time(s)
         149.pool85-49-8.dynamic.orange.es[85.49.8.149] 2 Time(s)
         1503021874.dhcp.dbnet.dk[89.150.75.50] 4 Time(s)
         152-60.go.evo.bg[85.217.152.60] 2 Time(s)
         156-90-99-58-T-tdtv.tinp.net.tw[58.99.90.156] 2 Time(s)
         167-68-246-201.adsl.terra.cl[201.246.68.167] 2 Time(s)
         168-226-244-166.mrse.com.ar[168.226.244.166] 2 Time(s)
...
         adsl-67-114-84-118.dsl.lsan03.pacbell.net[67.114.84.118] 2 Time(s)
         adsl-68-23-4-190.dsl.ipltin.ameritech.net[68.23.4.190] 2 Time(s)
         adsl-69-209-147-42.dsl.sfldmi.ameritech.net[69.209.147.42] 2 Time(s)
         adsl-69-209-154-96.dsl.sfldmi.ameritech.net[69.209.154.96] 2 Time(s)
...
         host234-234-static.116-81-b.business.telecomitalia.it[81.116.234.234] 2 Time(s)
         host241-167-dynamic.19-79-r.retail.telecomitalia.it[79.19.167.241] 2 Time(s)
         host246-209-dynamic.15-87-r.retail.telecomitalia.it[87.15.209.246] 2 Time(s)
         host248-13-dynamic.1-87-r.retail.telecomitalia.it[87.1.13.248] 2 Time(s)
...
         pool-71-241-246-243.washdc.fios.verizon.net[71.241.246.243] 2 Time(s)
         pool-71-244-163-181.chi01.dsl-w.verizon.net[71.244.163.181] 2 Time(s)
         pool-71-246-128-243.aubnin.fios.verizon.net[71.246.128.243] 2 Time(s)
         pool-71-251-115-130.tampfl.fios.verizon.net[71.251.115.130] 2 Time(s)
         pool-71-251-140-235.cmdnnj.east.verizon.net[71.251.140.235] 2 Time(s)
         pool-71-252-137-81.dllstx.fios.verizon.net[71.252.137.81] 2 Time(s)
         pool-71-99-87-26.tampfl.dsl-w.verizon.net[71.99.87.26] 6 Time(s)
...
         ppp83-237-30-117.pppoe.mtu-net.ru[83.237.30.117] 2 Time(s)
         ppp85-140-146-212.pppoe.mtu-net.ru[85.140.146.212] 2 Time(s)
         ppp85-140-21-109.pppoe.mtu-net.ru[85.140.21.109] 2 Time(s)
         ppp85-140-43-193.pppoe.mtu-net.ru[85.140.43.193] 2 Time(s)
         ppp85-141-174-160.pppoe.mtu-net.ru[85.141.174.160] 4 Time(s)
...
         unknown[116.22.163.196] 6 Time(s)
         unknown[116.45.106.170] 2 Time(s)
         unknown[117.12.65.40] 4 Time(s)
...

- 

Conclusion

N’hésitez pas, apt-get install postgrey, modif du fichier main.cf et reload de postfix. Ca prend 3 minutes et ça envoi du gros !

Tout d’abord, lisez la doc officielle de SpamAssassin sur le sujet, c’est la bible. Ensuite, voici un cas simple, concret, basé sur un header particulier, le champ "Received". Je cherche à voir si le mail spammeux non détecté est passé par le serveur « gaoland.net », apparement un « problème connu » (voyez sur Google).

J’ai donc créé un fichier /etc/spamassassin/mes_regles.cf contenant :

header   PERSO_GAOLAND Received =~ /gaoland\.net/i
describe PERSO_GAOLAND Relaye par gaoland.net, on soupçonne fortement
score    PERSO_GAOLAND 4.0

J’ai simplement fait ajouter 4 points car ce spam non reconnu marquait déjà 4.5 ou 4.9 – je ne sais plus – pour motif « Bayesian spam probability is 99 to 100% », mon seuil de détection étant à 5.

Pour faire un test de votre configuration, vous pouvez vous créer une règle de ce genre :

body     MESREGLES_TEST   /je teste mon spam/
score    MESREGLES_TEST   5.1

…et vous envoyer un e-mail depuis une adresse non whitelistée (oui oui j’ai fait cette erreur contenant dans le corps du message (BODY) la phrase « je teste mon spam ». Vous devriez alors voir un joli :

Spam detection software, running on the system "monserveur.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  bliblablo je teste mon spam blabslqj [...] 

Content analysis details:   (5.1 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 5.1 MESREGLES_TEST             BODY: MESREGLES_TEST
 0.0 BAYES_50               BODY: Bayesian spam probability is 40 to 60%
                            [score: 0.4978]
 0.0 AWL                    AWL: From: address is in the auto white-list

Et voilou

En fait, spamassassin 3.2 est packagé avec un mauvais module Perl ImageInfo, faisant appel à une méthode qui fait tout vautrer, l’erreur typique en lançant spamassassin --lint -D est ça :

[16752] warn: rules: failed to run CG_FUJI_JPG test, skipping:
[16752] warn:  (Can't locate object method "image_name_regex" via package "Mail::SpamAssassin::PerMsgStatus" at (eval 1274) line 819.
[16752] warn: )
[16752] warn: rules: failed to run CG_DOUBLEDOT_GIF test, skipping:
[16752] warn:  (Can't locate object method "image_name_regex" via package "Mail::SpamAssassin::PerMsgStatus" at (eval 1274) line 964.
[16752] warn: )
[16752] warn: rules: failed to run CG_SONY_JPG test, skipping:
[16752] warn:  (Can't locate object method "image_name_regex" via package "Mail::SpamAssassin::PerMsgStatus" at (eval 1274) line 1534.
[16752] warn: )
[16752] warn: rules: failed to run CG_CANON_JPG test, skipping:
[16752] warn:  (Can't locate object method "image_name_regex" via package "Mail::SpamAssassin::PerMsgStatus" at (eval 1274) line 2554.
[16752] warn: )

Il faut donc simplement redescendre le bon ImageInfo.pm et imageinfo.cf respectivement dans /usr/share/perl5/Mail/SpamAssassin/Plugin et dans /etc/spamassassin. Hop, c’est réglé.

Note : si vous avez installé les règles de SARE après SpamAssassin 3.2, vous n’avez pas constaté le bug, forcément.