Je vais proposer un “patch” pour le module “SPF.pm” de “spamassassin”, afin qu'il tolère les réponses “softfail” comme il le fait pour “pass” en règle SPF .

~~READMORE~~

Il est des légendes urbaines tenaces, et l'une d'elle est lié à la configuration des e-mails.

Qui n'a pas entendu dire:
“Pour configurer son mail, il faut utiliser le service SMTP de son fournisseur d'accès !”

Ça eu été vrai avec feu AOL ou feu CompuServe… mais plus aujourd'hui.

Donc, quand vous avez un compte mail a configurer:
UTILISER LE SERVEUR SMTP DE VOTRE FOURNISSEUR DE MAIL (et non pas d'“accès”).

Exemples:

• Vous configurez un compte mail chez “gmail.com”.

Où que vous soyez, utilisez son service SMTP, comme “smtp.gmail.com”.

• Vous configurez un compte mail “free.fr” :

Où que vous soyez, utilisez son service SMTP, comme “smtp.free.fr”.

• Vous configurez un compte mail de chez “trouduc.com” :

Exigez un service d'envoi SMTP, genre: “smtp.trouduc.com”.

Etc…
Le petit truc un peu rébarbatif , c'est qu'il vous faudra entrer un mot de passe, et peut être utiliser le port 587 au lieu du port 25.

Malgré le conseil ci-dessus, des utilisateurs, souvent âgés et obtus (haha!), refusent d'adapter leur configuration aux temps modernes.
Donc, quand on utilise des règles SPF , et bien on se retrouve avec des utilisateurs (âgés et obtus) qui rouspètent parce que leur mails sont rejetés.

On peut assouplir les règles SPF pour tolérer ces gougnafiers: on configure le SPF de telle sorte qu'il émette un avertissement sous forme d'un “softfail” pour certaines plages d'IP, et ça passe…

Enfin, presque:
Certains scripts vont traiter une réponse “softfail” comme un rejet: ce qui n'est pas le cas. (de même que “neutral”, mais je m'en fous).

C'est ce qui arrive avec le plugin/script “SPF” qui vient avec “spamassassin”.

On va devoir modifier le source pour qu'il accepte les “softfail” comme un “pass”, et pour cela, j'ai fait un patch.

Exemple de configuration qu'on peut trouver dans “/etc/spamassassin/local.cf” :

whitelist_from_spf *@tjaouen.fr
def_whitelist_from_spf *@microsoft.com *@gmail.fr
whitelist_auth fhollande@gouv.fr

Si l'un des cas retourne pour le test SPF “softfail”, il sera considéré comme un problème, et donc, ne saura pas whitelisté: c'est un peu trop sévère à mon goût.

Je vais proposer 2 méthodes pour tolérer les “softfail”.

La première va simplement autoriser les “softfail” pour les listes “whitelist_from_spf” et “whitelist_auth”.

La deuxième va utiliser une autre liste créée pour l'occasion et nommé “whitelist_from_spf_softfail”.

Le patch pour “Debian Jessie” :

• Patch: SPF-softfail-v2-jessie.patch.txt
• Zippé: SPF-softfail-v2-jessie.patch.txt.zip

Le patch pour “Debian Wheezy” :

• Patch: SPF-softfail-v2.patch.txt
• Zippé: SPF-softfail-v2.patch.txt.zip

Si nécessaire:

# aptitude update && aptitude install patch

Rechercher où se trouve le script a patcher:

# dpkg -S SPF.pm

On va dans le répertoire:

# cd /usr/share/perl5/Mail/SpamAssassin/Plugin

On fait un backup (toujours!) :

# cp -p SPF.pm{,-backup}

Le patch ne pourra s'appliquer que sur le fichier “SPF.pm” original venant que Debian Jessie ou Debian Wheezy.

Appliquer le patch:

# patch -p0 <SPF-softfail-v2.patch.txt 
patching file SPF.pm

Recharger “spamassassin” :

# /etc/init.d/spamassassin reload

Pour activer le traitement des “softfail” en équivalent de “pass” , il suffit d'ajouter dans la conf de “spamassassin” :

wl_ignore_spf_softfail 1

(Par defaut, c'est '0', bien sur)
Pour ma part, cette option a été ajouté dans /etc/spamassassin/local.cf .

Maintenant, on recharge la conf, est c'est fini:

# /etc/init.d/spamassassin reload

Le comportement associé à la liste “whitelist_from_spf” (et incidement, “whitelist_auth”) est changé.
Une réponse “softfail” est équivalent à “pass”.

Cela ne change rien pour “def_whitelist_from_spf”

Sinon, on peut ajouter les adresses a une nouvelle liste créé par le patch.

Il s'agit de “whitelist_from_spf_softfail” .

Exemple:

whitelist_from_spf_softfail *@gmail.com
whitelist_from_spf_softfail toto@trouduc.fr

Mais il faut aussi ajouter ça dans /etc/spamassassin/local.cf (ou équivalent):

ifplugin Mail::SpamAssassin::Plugin::SPF

header USER_IN_SPF_SOFTFAIL_WHITELIST   eval:check_for_spf_softfail_whitelist_from()
describe USER_IN_SPF_SOFTFAIL_WHITELIST From: address is in the user's SPF SOFTFAIL whitelist
tflags USER_IN_SPF_SOFTFAIL_WHITELIST   userconf nice noautolearn
score USER_IN_SPF_SOFTFAIL_WHITELIST    -100.000

endif # Mail::SpamAssassin::Plugin::SPF

Adapter le “score” selon vos envies, mais ne changez rien au reste.

Et pour activer la nouvelle configuration, comme d'habitude:

# /etc/init.d/spamassassin reload

Pour voir les messages de debug d'un service, par exemple “spf”, on fera en sorte que “spamassassin” démarre avec l'option “-D spf”.

Exemple, dans “/etc/default/spamassassin”, j'ai simplement fait cette modif:

OPTIONS="--create-prefs --max-children 5 --helper-home-dir --ipv4only -D spf"

Si le patch n'est pas appliqué correctement, vous pourrez voir une erreur comme ça dans les logs:

Nov  31 05:40:06 mx9 spamd[24215]: config: failed to parse line, skipping, in "/etc/spamassassin/local.cf": wl_ignore_spf_softfail 1

Ou encore:

Nov 31 05:52:48 mx1 spamd[2274]: rules: failed to run USER_IN_SPF_SOFTFAIL_WHITELIST test, skipping:
Nov 31 05:52:48 mx1 spamd[2274]:  (Can't locate object method "check_for_spf_softfail_whitelist_from" via package "Mail: [...]:SpamAssassin::PerMsgStatus" at (eval 1154) line 1558.
Nov 31 05:52:48 mx1 spamd[2274]: )

A l'inverse, vous pourriez voir:

Nov  31 06:11:27 mx0 spamd[24700]: spf: ignoring softfail from whitelist, by admin setting

Le patch a été fait comme cela:

$ diff -Naur SPF.pm SPF-softfail-v2.pm > SPF-softfail-v2.patch.txt