On Thu, 28 Jun 2007, Stephane Bortzmeyer wrote: > On Thu, Jun 28, 2007 at 09:15:43AM +0200, > Dominique Rousseau <[EMAIL PROTECTED]> wrote > a message of 31 lines which said: > > > Et les premiers à utiliser des enregistrements SPF ont été des > > spameurs > > Et les gens malhonnêtes ont des cartes d'identité eux aussi. Faut > arrêter cet argument, qui consiste à confondre l'authentification et > l'autorisation. SPF est une (bonne) technique d'authentification, pas > d'autorisation (et ce n'est donc pas, utilisé seul, un outil > « anti-spam »).
Tout-à-fait. J'ajouterais même que :
- le SPF n'est pas une technique de lutte contre le spam, mais contre
l'usurpation d'identité (ou devrais-je dire, de nom de domaine). Vous
pouvez protéger votre nom de domaine en publiant des enregistrements
SPF. Mais du même coup vous faites "whitelister" les spams qui partent
depuis votre propre réseau ou via votre propre MTA. Il faut plutôt
rapprocher SPF du phishing. Idem pour DKIM, ça ne va pas résoudre le
problème du spam. (qu'est-ce qui empêche un spammeur de créer son
propre domaine et d'envoyer des spams bien propres du point de vue SPF
ou DKIM?)
- le SPF ne sera efficace (contre le phishing, pas le spam) que si tout
le monde s'en sert, on en est loin.
- côté retour d'expérience sur 14.000 comptes mails, pour avoir essayé
de coupler SPF et greylisting (comprendre: on greyliste si le test SPF
renvoie "soft-fail" et/ou "hard-fail", sinon on laisse passer), j'ai
vite abandonné, très faible bénéfice, et beaucoup trop de faux positifs :
- les admins qui ne comprennent pas comment marche SPF.
- ceux qui croient qu'on ne peut pas envoyer du courriel professionnel
depuis sa *box chez soi.
- les .forward et autres mailing lists ne réécrivant pas le from
d'enveloppe.
Cf SRS pour la réécriture du from (www.libsrs2.org).
Par comparaison, la même technique associée aux RBL (greylist si RBL)
donne de bien meilleurs résultats, et bien moins de faux-positifs.
- par contre, publier des enregistrements SPF corrects, implémenter SRS,
utiliser un domaine dédié sur vos MTA (@returns.domain.tld), etc, vous
aide à ne pas voir vos courriels considérés comme spams par des
personnes qui font trop confiance à SPF. Mais l'utiliser en tant que
technique de filtrage en réception, bof bof.
Pour revenir au port 25, c'est effectivement une tendance nécessaire
aujourd'hui et démarrée depuis 1-2 ans, mais ça n'est pas parfait :
- c'est une technique qui n'est efficace (contre le spam) que si tout le
monde l'implémente (intelligemment) , et :
- cela va déplacer le problème du spam sur les serveurs légitimes du
FAI. Le FAI devra donc implémenter du filtrage côté abonnés (si ce
n'est pas déjà fait), ou alors augmenter les tuyaux pour laisser sortir
le spam (au risque de se faire blacklister d'autres FAI). Dans les
deux cas c'est coûteux, et on comprend pourquoi les FAI ne sont pas
aussi rapides qu'on le souhaiterait à franchir le pas. A cela
s'ajoutent les risques contractuels et les difficultés techniques.
Il y a bien la solution d'utiliser le port "submission" et même de faire
de l'authentification pour la soumission par le end-user, mais là encore
ça ne va durer qu'un temps... les vers sont tout-à-fait capables de
récupérer les paramètres et le mot de passe pour la soumission SMTP.
Tout ce qu'un utilisateur peut faire avec sa machine, un vers arrivera à
le rejouer, c'est une question de moyens ! De là à utiliser des tockens
et du one-time-password pour envoyer du mail... peut-être pas.
--
Raphaël Marichez
[EMAIL PROTECTED]
Hervé Schauer Consultants (HSC)
pgpgbBYNTYBri.pgp
Description: PGP signature
