Sommaire
Bonjour Nal.
Administrer son serveur de messagerie, c'est cool. Se faire blinder ses boites mails de SPAM, ça l'est moins. Il existe plein de méthodes subtiles et inefficaces pour bloquer les SPAM tout en laissant passer les mail légitimes. Nous allons voir qu'avec un simple Hack de spf-policyd, la subtilité c'est pour les faibles et les couards !
Le contexte
Configurer un systeme anti-spam sous postfix est une vrai misère. Même s'il existe des très bons tutos, ils impliquent tous de nombreuses étapes de configurations complexes. De plus, il est souvent nécessaire d'utiliser des services tiers pour qualifier le niveau de confiance du serveur émetteur.
La methode usuelle
L'idée est de se concentrer sur le SPF. Je pars du principe que si quelqu'un administre un serveur de mail il DOIT avoir correctement configuré au moins le champ SPF du DNS lié à son domaine. C'est ultra basique et indispensable pour envoyer des mail vers des adresses gmail ou outlook. Ces derniers ne respectant pas trop les RFCs.
La verification du SPF consiste à dire à votre serveur mail que lorsqu'il reçoit un mail, il doit verifier si l'IP du serveur émetteur correspond à l'IP du serveur officiellement déclaré de ce domaine.
Cette vérification peut être effectuée par un utilitaire nommé spf-policyd. Le problème c'est que cet utilitaire fonctionne uniquement si le domaine indiqué comme etant celui de l'émetteur déclare effectivement un champ SPF dans son DNS. Dans le cas ou rien ne serait déclaré, spf-policyd laisse passer le mail. Un peu embettant non ?
Du coup il est normalement nécessaire de coupler spf-policyd avec DKIM, DMARC et spamassasin pour être certain de couvrir tous les cas possibles.
Qu'a cela ne tienne, nous allons faire comme Google et Microsoft !
Le hack
L'idée simple est de modifier spf-policyd pour qu'il rejette les mails si le SPF de l'emetteur n'existe pas (résultat "None"). La fonction de base, qui rejette le mail si le SPF ne correspond pas (résultat "Fail") continuera de fonctionner normalement. On va simplement rendre spf-policyd un peut plus aggressif.
Sous Débian 10 et ubuntu 20.04, apres avoir installé et configuré le paquet postfix-policyd-spf-python, il faut éditer le fichier /usr/lib/python3/dist-packages/spf_engine/__init__.py
A la ligne 159, sous le bloc suivant :
if mfrom_policy == 'SPF_Not_Pass':
try:
unused_results.remove('Fail')
actions['reject'].append('Fail')
unused_results.remove('Softfail')
actions['reject'].append('Softfail')
unused_results.remove('Neutral')
actions['reject'].append('Neutral')
except:
if debugLevel >= 2: syslog.syslog('Configuration File parsing error: Mail_From_reject')Ajouter ces lignes suivantes apres "exept :, if debug…":
# Hack de selenith
elif mfrom_policy == 'Cerbere':
try:
unused_results.remove('Fail')
actions['reject'].append('Fail')
unused_results.remove('Softfail')
actions['reject'].append('Softfail')
unused_results.remove('None')
actions['reject'].append('None')
except:
if debugLevel >= 2: syslog.syslog('Configuration File parsing error: Mail_From_reject')La section devrait donc ressembler à ceci :
if scope == 'mfrom':
mfrom_policy = configData.get('Mail_From_reject')
if "@" in sender:
sender_domain = sender.split('@', 1)[1]
else:
sender_domain = ''
if spf.domainmatch(reject_domain_list, sender_domain):
mfrom_policy = 'SPF_Not_Pass'
local['local_mfrom'] = True
if mfrom_policy == 'SPF_Not_Pass':
try:
unused_results.remove('Fail')
actions['reject'].append('Fail')
unused_results.remove('Softfail')
actions['reject'].append('Softfail')
unused_results.remove('Neutral')
actions['reject'].append('Neutral')
except:
if debugLevel >= 2: syslog.syslog('Configuration File parsing error: Mail_From_reject')
# Hack de selenith
elif mfrom_policy == 'Cerbere':
try:
unused_results.remove('Fail')
actions['reject'].append('Fail')
unused_results.remove('Softfail')
actions['reject'].append('Softfail')
unused_results.remove('None')
actions['reject'].append('None')
except:
if debugLevel >= 2: syslog.syslog('Configuration File parsing error: Mail_From_reject')
elif mfrom_policy == 'Softfail':
try:
unused_results.remove('Fail')Avec ce petit patch, il va être necessaire de mettre en liste blanche les domaines des serveurs mail émetteurs qu'on peut considérer comme sûrs, mais dont les champs SPF sont mal ou non configurés.
Pour cela on va éditer le fichier de config /etc/postfix-policyd-spf-python/policyd-spf.conf
Ajouter en fin de fichier les lignes suivantes :
# Domaines des adresses emails emetteurs autorisés (mfrom)
# Valide seulement si le SPF du domaine est configuré. Si SPF : None => utiliser HELO_Whitelist
Domain_Whitelist = freetelecom.fr,linuxfr.org,outlook.com,sfr.fr,orange.fr,google.com
# Domaines des serveurs emetteurs autorisé (HELO)
HELO_Whitelist = free.fr,freetelecom.fr,amazonses.com,gouv.fr,outlook.com,sfr.fr,orange.fr,google.com,linkedin.comEt pour finir on active notre patch en modifiant la valeur Mail_From_reject comme ceci (toujours dans policyd-spf.conf):
# Mail_From_reject = Fail
Mail_From_reject = CerbereEn ayant appliqué le patch dans la section qu'on a nommé "Cerbere", on peut l'activer ou le désactiver à la volée en changeant la valeur de Mail_From_reject de Fail à Cerbere.
J'ai mis les principaux domaines avec lesquels j'ai déja rencontrés des soucis.
A vous de compléter ou de modifier avec les domaines que vous trouvez pertinent et dont les champs SPF sont mal configurés (oui c'est toi que je regarde, le site des impots).
Retex
En ayant fait ce petit hack sur ma propre config, je suis passé de plusieurs centaines de spams (sur l'ensemble des boites que je gère) par jour à 0.
Il arrive que je doive ajouter un domaine en whitelist, mais c'est anecdotique (une fois tous les 6-8 mois).
Avec ce simple hack, j'ai pu drastiquement diminuer le temps de Maintient en Condition Opérationnelle (MCO) de mon serveur de mail. Et le tout sans passer par une base de donnée externe pour vérifier les domaines de confiance.
N'hésitez pas à tester sur votre propre serveur, je suis friand de vos retours.
# Pas convaincu
Posté par Pol' uX (site web personnel) . Évalué à 10.
Outre la règle idiote d'exiger un SPF alors que SPF casse l'email, les spammeurs gère très bien SPF. Exemple sur un tout petit mx depuis ce matin:
=> 32 messages présentés avec un SPF niquel mais taggués comme spam par le rspamd local.
Adhérer à l'April, ça vous tente ?
[^] # Re: Pas convaincu
Posté par Selenith (site web personnel) . Évalué à 1. Dernière modification le 22 avril 2021 à 16:51.
C'est pourtant le choix que Google a fait pour gmail.
Si tu as déjà tenté d'envoyer un mail depuis ton domaine vers un gmail sans SPF, tu as du constaté assez rapidement qu'ils sont tous rejetés avec un beau message du type "no SPF record found".
Pour mon information, combien de SPAM sur la même période sont rejetés avec un SPF invalide ? Je suis curieux de connaitre le ratio.
[^] # Re: Pas convaincu
Posté par Pol' uX (site web personnel) . Évalué à 10.
Que Google impose sa puissance aux autres c'est une chose. Que tu fasse pire que mieux en est une autre.
Sur ce même serveur depuis ce matin :
Il y a aussi les SPF invalides et les SPF pas respectés : parfois c'est du spam, parfois c'est des problèmes de configuration, parfois c'est à cause du fait que SPF casse l'email, et parfois c'est des pannes…
Adhérer à l'April, ça vous tente ?
[^] # Re: Pas convaincu
Posté par Selenith (site web personnel) . Évalué à 1.
Merci pour l'info. Cela fait étonnamment peu de spam. Ton retour sur les SPAM avec des SPF corrects m'interroge. C'est quelque chose que je n'ai, pour le moment, pas constaté.
C'est un serveur d'entreprise ou un de type familiale ? Du genre avec des enfants qui renseignent leur adresse mail dans tous les sites qu'il croisent '
Si tu passe l'intro un peu putacière, je te le concède, tu verras qu'en fin d'article je parle de whitelist. De fait, je n'impose rien a qui que ce soit. Si je ne reçois pas le mail d'un domaine sans SPF configuré (ce qui n'est pas tout a fait RCF 7208 complient j'en conviens). Je l'ajoute simplement en whitelist.
J'ai constaté que la plupart du temps lorsque je recevais un mail d'une entreprise française avec un SPF non configuré, elle passait simplement par les serveurs relais de sont FAI. Ces domaines sont présents dans la whitelist que je donne.
[^] # Re: Pas convaincu
Posté par J Avd . Évalué à 3.
Salut,
Peux-tu être plus explicite ?
Sans être une élite du smtp, je connais assez bien ce domaine et tu es bien la première personne que j'entends s'attaquer à SPF en des termes si rédhibitoires.
Cordialement,
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: Pas convaincu
Posté par jyes . Évalué à 10.
L’auteur du journal répond lui-même à ta question. C’est dans le cœur du courrier électronique que de pouvoir déléguer le transport à des serveurs relais, ce que casse SPF. Du coup, SPF pour repérer des comportements inattendus, pourquoi pas, mais il faut garder en tête que de nombreux usages légitimes ne respecteront pas cette règle. Bloquer trop fort sur ce critère aboutit à la solution proposée dans le journal qui consiste à gérer une liste d’exceptions autorisées à court-circuiter cette vérification, et cette liste d’exceptions comprend très vite tous les gros acteurs. Au final, la solution proposée dans le journal revient peu ou prou à refuser les e-mails de tous sauf des très gros. C’est effectivement ce que font déjà certains gros acteurs, qui considèrent que si ton courriel n’est ni Gmail, ni Outlook, il ne doit pas être légitime, mais le journal répand la pratique et la défend pour l’auto-hébergement.
[^] # Re: Pas convaincu
Posté par Selenith (site web personnel) . Évalué à 1.
La declaration SPF est parfaitement compatible avec la délégation. Elle ne casse rien.
C'est exactement la configuration qu'on utilise dans la boite pour laquelle je travaille.
D'ailleurs, pour l'anecdote, jusqu'à ce que je leur propose de faire une déclaration SPF dans notre DNS, certains clients et partenaires recevaient systématiquement nos mails en tant que SPAM (voir ne recevaient qu'une partie des mails). Et je parle ici de gros acteurs de l'industrie et des telecom. L'idée que je propose ici n'est donc ni nouvelle ni délirante. Je propose une implémentation simple et consommant peu de ressources. Comment regler ce type de comportement de spf-policyd est également une question que j'ai déjà croisé dans plusieurs forums.
La whitelist permet de ne pas rejeter les mails qui sont relayés par les gros FAI et dont le domaine d'émission ne déclarent pas de SPF. Ce qui est souvent le cas pour des petites entreprises sans informaticien qui disposent juste d'une plateforme d'e-commerce par exemple. Sachant que les FAI en question font déjà ce travaille de filtrage sur leur serveurs relais.
Comme je l'expliquais dans un autre commentaire, les autres restrictions sont toujours parfaitement opérationnelles. Le check SPF étant effectué en fin de séquence de toutes les autres policy.
[^] # Re: Pas convaincu
Posté par J Avd . Évalué à 1.
Ok get it !
Merci pour la réponse :p
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: Pas convaincu
Posté par Pol' uX (site web personnel) . Évalué à 7.
Quelques exemples:
- SPF n'est pas compatible avec les listes de discussion. Il force à munger les champs from:
- SPF n'est pas compatible avec les aliases/.forward. Il force à faire du SRS qui par ailleurs pose des problèmes.
- SPF n'est pas compatible avec les redirections.
Ces trois exemples sont des usages établis/répandus du courriel dont SPF complique ou décourage la pratique.
Le tout pour un apport quasi nul puisque les spammeurs gèrent très bien SPF (la preuve: aucun antispam ne donne des bons points en nombre significatif à un mail qui présente un SPF bien configuré).
Dans la vraie vie, SPF servirait à :
- mettre à la poubelle vos cartes postales et/ou courriers expédiés depuis ailleurs que chez vous ;
- mettre à la poubelle le courrier des SDF ;
- mettre à la poubelle le courrier des petites assos et/ou de toute organisation qui n'a pas pris le temps d'enregistrer une adresse auprès de l'administration centrale.
Mais ça n'éviterait pas la pub.
Adhérer à l'April, ça vous tente ?
[^] # Re: Pas convaincu
Posté par J Avd . Évalué à 2.
Ok merci pour vos réponses !
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: Pas convaincu
Posté par cg . Évalué à 1.
Hello,
J'ai un doute là-dessus, quand même. Il me semble qu'il y a confusion entre
From,From:, etMAIL FROM:. À priori un filtre SPF s'intéresse surtout àMAIL FROM:, non ?[^] # Re: Pas convaincu
Posté par Pol' uX (site web personnel) . Évalué à 4. Dernière modification le 08 mai 2021 à 14:17.
Oui mais un malheur n'arrive jamais seul. Vu que SPF ne suffit pas, des gens ont inventé dmarc.
https://www.bortzmeyer.org/7960.html
https://sympa-community.github.io/manual/customize/dmarc-protection.html
https://www.rfc-editor.org/rfc/rfc7960.html#section-4.1.3.3
Adhérer à l'April, ça vous tente ?
[^] # Re: Pas convaincu
Posté par cg . Évalué à 1.
Merci, le texte de Stéphane est clair !
[^] # Re: Pas convaincu
Posté par Donk . Évalué à 3.
Et c'est là que ARC entre en jeu:
https://replay.jres.org/videos/watch/2bb86882-cbac-47f9-ad26-36a451d168f6?start=18m34s
https://en.wikipedia.org/wiki/Authenticated_Received_Chain
[^] # Re: Pas convaincu
Posté par Misc (site web personnel) . Évalué à 9. Dernière modification le 22 avril 2021 à 20:07.
Je suis sur qu'il y a pas de SPF sur un des domaines que je gère (je viens de vérifier), j'ai installé un nouveau serveur de liste de discussions et Google n'a pas l'air de jeter les emails.
Et les gens m'auraient prévenu si on avait un souci.
[^] # Re: Pas convaincu
Posté par Joris Dedieu (site web personnel) . Évalué à 4. Dernière modification le 29 avril 2021 à 17:44.
[^] # Re: Pas convaincu
Posté par Donk . Évalué à 3.
Le domaine edf.fr a une règle DMARC avec p=none
[^] # Re: Pas convaincu
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 2.
Je me suis permis d'anonymiser l'adresse mail gmail.
[^] # Re: Pas convaincu
Posté par Tonton Th (Mastodon) . Évalué à 2.
Et qu'en pense madame Redacted ?
# Autre astuce à utiliser ou non en combinaison avec la solution proposée dans ce journal
Posté par jyes . Évalué à 10. Dernière modification le 22 avril 2021 à 16:55.
À l’instar de ceux qui changent le port de SSH vers un autre que 22 pour se prémunir des attaques potentielles, changer le port d’écoute de postfix vers quelque chose de différent de 25 est extrêmement efficace contre le spam. Comme toutes les solutions anti-spam efficaces, ça peut filtrer un peu trop fort mais au moins aucun spam ne passe.
Avis à tous les administrateurs de messagerie électronique amateurs, suivez bien tous les tutoriaux anti-spam que vous trouvez sur le web. Pour les plus paresseux, voici comment faire : éditez le fichier
/etc/postfix/master.cfet remplacez la lignepar
Puisque vous avez déjà changé le port pour SSH vers autre chose, autant réutiliser ce port libéré.
De rien et bonne continuation avec vos serveurs de messagerie !
[^] # Re: Autre astuce à utiliser ou non en combinaison avec la solution proposée dans ce journal
Posté par Selenith (site web personnel) . Évalué à 1.
Même s'il s'agit la d'un troll grossier envers mon article, je dois admettre que j'ai rit.
Tu parles ici d'administrateurs amateurs. Ta réflexion est intéressante. J'ai vu ici même, sur linuxfr, nombre de commentaires de personnes disant ne pas vouloir administrer leur probre serveur de messagerie principalement a cause du problème de spam.
Si on met de coté la question de la configuration initiale et la sécurisation du serveur, l'installation et la gestion des services antiSPAM est une horreur. Et même avec dkim,dmarc, etc, il y a toujours des faux positifs/négatifs.
Mon but ici est de proposer une petite modif toute bête qui peut permettre a ceux qui voudraient se lancer dans la décentralisation de leur boite mail une solution simple et efficace.
Pour info, mes adresses mails sont exposées sur mon site web a la merci des robots spammeurs. Et cette simple modif me permet d'être malgres tout serein.
Mais tu as raison on peut aussi laisser les "pro" faire et utiliser les services gratuits d'outlook et de gmail.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Autre astuce à utiliser ou non en combinaison avec la solution proposée dans ce journal
Posté par Selenith (site web personnel) . Évalué à 0.
sfr.fr et free.fr, par exemple, sont utilisés comme serveurs relais par nombre de serveurs de petites entreprises dont ils sont le FAI.
Tu te retrouve donc avec un serveur en xxxxxx.sfr.fr qui te délivre un mail de jean-michel@super-plaquiste.fr.
J'admets que la gestion de la whitelist peut être rebutante, mais avec celle que je donne dans ce journal, je couvre déja une bonne partie des expediteurs francais dont le SPF n'est pas configuré.
# modification de fichiers gérés par un paquet
Posté par Yann 'Ze' Richard (site web personnel) . Évalué à 9.
Attention, tu modifies un fichier géré par un paquet Debian. Lors d'une mise à jour du paquet ton patch sautera.
Alors pour ce paquet la ca n'arrive pas souvent mais ca arrive.
[^] # Re: modification de fichiers gérés par un paquet
Posté par barmic 🦦 . Évalué à 8.
Pour ça il est possible d'utiliser dpkg-divert qui est fais pour ça. Ça ne garanti pas que ça ne va pas finir par casser quelque chose, mais c'est la méthode. Les quelques rares fois où je m'en suis servi c'est pour faire du wrapping ou pour des paquets qui ne venaient pas des dépots debian.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: modification de fichiers gérés par un paquet
Posté par Selenith (site web personnel) . Évalué à 1.
Tu as raison. Étant donné que je présente la modif comme un hack, c’était pour moi implicite. Mais l'explicite étant préférable, j'aurais dû le préciser.
# Détection pour ajout en liste blanche
Posté par Glandos . Évalué à 3.
Et du coup, c'est quoi la procédure pour se rendre compte qu'il faut ajouter un domaine en liste blanche ?
[^] # Re: Détection pour ajout en liste blanche
Posté par Selenith (site web personnel) . Évalué à 2. Dernière modification le 22 avril 2021 à 21:31.
Je me construis un rapport d’après les fichiers de log sur serveur.
Je commence par un simple grep en cherchant les messages jetés à cause du SPF :
Mais vu que c'est assez illisible, je capture les infos pertinentes, (from, to et helo) avec sed et je les formate avec column:
Ca me donne un truc du genre :
Avec dans l'ordre date, expediteur, serveur délivrant le mail, destinataire.
En mettant ça dans un cron ou un timer systemd, il est possible de se l'envoyer par mail X fois par semaine pour monitorer ce qui se passe sur le serveur.
[^] # Re: Détection pour ajout en liste blanche
Posté par eingousef . Évalué à 10.
Apparemment il faut que ce soit tenu par des gens douteux.
*splash!*
# moui
Posté par steph1978 . Évalué à 9.
Il doit y avoir des milliers de domains avec un SPF correct et que des spammers peuvent utiliser.
Mais le plus bizarre : si un spammer spoof un des domaines que tu as whitelisté (= bypass de la verif SPF), alors ça passe. Et les tiens sont pas difficile à deviner.
[^] # Re: moui
Posté par Selenith (site web personnel) . Évalué à 2.
Le check SPF vient en dernier après tous les autres check de postfix. Si le mail tente de spoofer un des domaines whitelisté, il est rejeté avant par les autres restrictions de type recipient_restrictions, sender_restrictions et helo_restrictions.
# Petit sondage
Posté par Astaoth . Évalué à 5.
Au vu des différents commentaires vu ici et là sur DLFP parlant du spam comme une calamité de l'auto-hébergement, je me demandais : parmi ceux qui hébergent leur propre serveur de mail pour un usage perso (ou familial), recevez-vous beaucoup de spam ? Si oui, depuis combien de temps votre serveur est en marche ? Etes-vous seul utilisateur de votre serveur ?
Emacs le fait depuis 30 ans.
[^] # Re: Petit sondage
Posté par Ericounet . Évalué à 2.
Bonjour,
j'administre mon serveur perso depuis 2006.
Je n'ai pas mis de détecteur/filtre de spams, mais SPF, DKIM, DMARC.
(pas encore DNSSSEC ni DANE … en projet!)
Et je n'en reçois que très peu. Nous sommes 5 utilisateurs.
Eric
[^] # Re: Petit sondage
Posté par jyes . Évalué à 3. Dernière modification le 23 avril 2021 à 09:11.
Situation très similaire pour moi. Serveur auto-hébergé depuis 2008, une poignée d’utilisateurs mais seulement 3-4 comptes qui utilisent leur courriel de manière active. Mon adresse est la plus ancienne (2008 donc), et sans anti-spam je n’en reçois pas (j’allais écrire quasiment pas, mais vraiment c’est tout proche de zéro). Les seuls « spam » que je reçois régulièrement sont envoyés par des boites à qui j‘ai dû fournir une adresse et qui en profitent pour se faire un peu de pub, mais je le vois vite car j‘utilise pour ça des adresses rallongées avec le nom de la boîte en question. J’ai appris à certains de mes utilisateurs à faire de même, ils ont donc peut-être une hygiène numérique supérieure à la moyenne. De plus, ces boites appliquent en général bien les demandes de désinscription.
Comme je ne suis qu’administrateur amateur, depuis un peu plus d’un an, je suis passé à Yunohost pour administrer mon serveur de messagerie électronique, ça m‘évite les bidouilles comme celles proposées dans ce journal qui impose de maintenir une liste de domaines exemptés de SPF qui contient presque le monde entier, dont les plus gros spammeurs. J’ai DKIM, SPF et DNSSEC d’activés. Ce matin, je viens de voir une tentative infructueuse de contacter contact@, sales@, adam@, mail@, office@, ian@, david@, chris@, john@ et mike@ mais mes quelques utilisateurs ne s’appellent pas comme ça.
[^] # Re: Petit sondage
Posté par Glandos . Évalué à 3.
(Cette image ne sera plus disponible dans un mois)
[^] # Re: Petit sondage
Posté par jihele . Évalué à 3.
Ca veut dire que pour trois message correct tu reçois un spam marqué dans ta boîte ? C'est beaucoup de spam, non ? Enfin si c'est combiné avec déplacement vers répertoire spécifique en aval, ça va.
[^] # Re: Petit sondage
Posté par jihele . Évalué à 2.
Serveur perso. On doit être 4 ou 5 dessus. Deux-trois règles de base dans Postfix pour virer les connexions qui respectent vraiment pas les protocoles (je sais pas combien ça représente). Config spamassassin par défaut. Je crois que spamassassin fait bien le boulot. Pas de faux positifs. Et il en passe un peu mais ça va (disons 1 ou 2 spams par jour, c'est pas la folie). Et j'ai jamais activé l'apprentissage bayesien ni modifié la config. Juste réglé des seuils pour marquer spam ou supprimer.
[^] # Re: Petit sondage
Posté par gouttegd . Évalué à 9.
Franchement, je peste beaucoup plus contre les mesures anti-spam à la truelle de certains serveurs que contre les émetteurs de spam…
Et il n’y a pas que les « gros serveurs » qui font de l’anti-spam en mode « je tire d’abord et je demande qui va là ensuite ». Microsoft est le grand champion en la matière, certes (en France SFR est pas mal aussi d’après les postmasters de Framasoft), mais il y a aussi pas mal de petits serveurs auto-administrés qui font n’importe quoi — genre utiliser des DNS blocklists connues pour blocklister des réseaux entiers et considérer la présence dans une seule de ces listes comme une raison entièrement suffisante pour rejeter un message, indépendamment de tout le reste…
Sur les cinq derniers jours, mon serveur a rejeté 124 mails invalidés par SPF (cas où le message provient d’une adresse non listée par l’enregistrement SPF du domaine prétendument émetteur, et où le même enregistrement annonce une politique stricte autorisant quiconque à refuser tout message venant d’une autre adresse), et 503 mails adressés à des utilisateurs inexistants.
Dans le même temps, une trentaine d’autres messages indésirables (mais envoyés à une de mes adresses valides et non bloqués par SPF — soit parce que le domaine émetteur n’a pas d’enregistrement SPF, soit parce que l’enregistrement a une politique non-stricte, soit parce que le message est valide du point de vue de SPF) sont arrivés et ont tous été correctement marqués comme indésirable par bogofilter, et ont donc été directement stockés dans la boîte de réception appropriée (où concrètement ils ne dérangent personne, je ne consulte cette boîte qu’une fois de temps en temps juste pour m’assurer qu’il n’y a pas de faux positifs — je peux encore compter sur les doigts d’une seule main les fois où c’est arrivé).
… Oh merde, ça fait plus de dix ans maintenant…
Oui.
[^] # Re: Petit sondage
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
D’autant plus que j’ai vu certaines de ces listes ne proposer comme seule solution pour être retiré de la liste noire… de les payer en bitcoin.
Ça pue l’escroquerie, et ceux qui utilisent des liste de liste noire sans discernement participent à l’escroquerie.
Note: c’était il y a quelques années, je n’ai plus de référence précise en tête.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Petit sondage
Posté par Donk . Évalué à 3.
En voici une:
https://news.gandi.net/fr/2021/03/le-service-e-mail-de-gandi-impacte-par-un-blacklisting-de-organisation-uceprotect/
[^] # Re: Petit sondage
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Après quoi, citant la possibilité de payer pour ne pas attendre 7 jours, Gandi ajoute
Bon moi, l’expérience à laquelle je fait référence, c’était de payer pour se faire délister ou attendre plusieurs années.
C’est super agréable (sarcasme) quand tu loues un nouveau serveur et que tu découvres à la livraison que son IP est listée dans une telle liste. Dans ce genre de situation, attendre 7 jours me conviendrait, je retarderai donc d’une semaine la livraison du serveur… Et s’il faut louer un serveur chez un autre fournisseur pour faire proxy pendant une semaine ça va, pendant plusieurs années c’est autre chose.
Après il est vrai que là pour Gandi c’était tout une rangée, donc 7 jours ça fait long pour une rangée complète. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Petit sondage
Posté par Misc (site web personnel) . Évalué à 3.
Il y a beaucoup de listes de blocage de spam: https://www.dnsbl.info/
Et en effet, certaines demandent de l'argent, ce qui ressemble plus à une tentative de troll qu'autre chose. Les spammeurs ne vont pas payer (ça laisse une trace), les entreprises non plus (vu les tarifs et les conditions de paiement), et les particuliers non plus.
Donc je pense que c'est juste un moyen de réduire le support du coté des gens qui font la liste, car je ne vois pas vraiment ce genre de business avoir assez de succès pour financer autre chose qu'une bière par an.
J'ai commencé à me pencher un peu plus sur ça, car un serveur de listes de discussion dont je suis responsable a commencé à avoir beaucoup de spam à modérer (15 par jour).
Donc j'ai pris les logs, j'ai regardé les spams qui passent et j'ai quel RBL me permet de bloquer ça via Postfix (la stack logiciel était un chouia trop vielle pour faire plus, et j'ai repoussé l'upgrade trop longtemps, donc je me suis limité à des options simples).
Aprés 2/3j de vérif au doigt mouillé, j'ai pris "UCEPROTECT Blacklist LEVEL 3" en me disant "la description me parait pas mal".
2j après, j'ai un utilisateur qui m'a écrit, assez mécontent, pour me dire qu'il est bloqué sur son serveur auto administré chez linode.
Et en effet, en fouillant un peu, je vois que le site de uceprotect a un design des années 2000, et que ça ressemble à un projet d'une personne dans son coin. Et surtout que les 3 listes ne sont séparés par provenance comme la description sur dnsbl.info le laisse croire, mais par taille du blocage. UCE 1 => 1 serveur, UCE 2 => 1 range, UCE 3 => 1 ASN.
Du coup, en effet, c'est efficace mais problématique.
Et c'est ma faute, car j'ai:
- pas vérifié sommairement le site de la DNSBL
- pas fait de tests sur les faux positifs de la liste
- pas pris le temps de mettre en place un système plus souple que "ça passe, ça passe pas" (genre spamassasin)
À refaire, la bonne solution me semblerait de d'abord faire un serveur qui récolte les IPs et les mails des envoyeurs (via un filtre postfix). Aussitot, le serveur regarde les scores sur les DNSBLs, et je regarde si les envoyeurs sont sur une liste, pour classer en probablement spam, ou probablement pas spam.
À partir de la, on peut calculer une matrice de confusion de chaque DNSBL sur une période donné pour le traffic de son propre serveur et choisir.
Il y a des listes plus ou moins sérieuses, mais c'est assez difficile de choisir, car tout le monde y va de son analyse à l'arrache, au lieu de chercher des chiffres et d'avoir une approche plus scientifique (ce que je comprends, j'ai fait pareil).
[^] # Re: Petit sondage
Posté par Toufou (site web personnel) . Évalué à 3.
auto hébergé depuis 2001, même email, même domaine, pas d'antispam serveur et j'en reçois suffisamment peu pour ne pas chercher à mettre un antispam côté serveur, celui de TBird suffit largement. Le domaine a hébergé entre 10 et 2 boîtes mails suivant les époques.
Les seuls spams qui me posent problème sont ceux des sociétés qui ont 'légitimement' mon email et dont les messages peuvent être importants : banques, assurances, compagnies aériennes et autres marchands divers où j'ai un compte car c'est devenu obligatoire pour passer commande…
[^] # Re: Petit sondage
Posté par Raoul Hecky (site web personnel) . Évalué à 1.
Auto hébergé depuis plusieurs années, je suis passé par les phases de gestion manuelle de postfix+antispam+config a la main sur un Proxmox Mail Gateway en frontal (c'est un relais) pour l'envoi et la réception des mails. J'ai mis le Proxmox Mail Gateway sur un petit VPS en ligne et mon serveur de mail chez moi. Depuis que j'ai fait ca, j'ai grandement amélioré la maintenance a faire sur la partie mail. Je peux que conseiller cette solution pour les auto-hébergeurs, c'est un gain de temps indéniable.
[^] # Re: Petit sondage
Posté par Florence Birée (site web personnel) . Évalué à 4.
J'ai un serveur perso depuis… 2008, je crois.
Ce serveur hébergeait au début juste mes mails, et puis ceux des potes, et puis… maintenant une cinquantaine de personnes (c'est un petit chatons).
Je reçois un peu de spam, que je gère via bogofilter (apprentissage bayésien) et un apprentissage indépendant de chaque utilisateurice du serveur. Suivant les boîtes mails, certaines personnes ne l'utilisent pas (ou utilisent le filtre de Thunderbird). Pour ma part, je dois avoir une dizaine de spams par jours (j'en ai eu beaucoup plus, ça s'est calmé il y a quelques années sans action de ma part).
J'ai par contre beaucoup de spam sur mes listes mail (mailman2). Ça ne passe pas la barrière de la modération, mais c'est un taff pénible pour les admins des listes.
J'ai SPF, DKIM, DMARC, etc, mais c'est pour que mes mails soient acceptés ailleurs, je n'utilise pas tout ça en réception. (Pas encore DNSSEC, car j'ai eu le malheur de choisir il y 10 ans un domaine en .im… qui ne gère pas DNSSEC au niveau de sa racine).
Et pareil que gouttegd, mon principal problème, c'est que mes mails arrivent chez Microsoft…
[^] # Re: Petit sondage
Posté par fate . Évalué à 2.
Hébergeant mon serveur mail (postfix/dovecot) depuis 4-5 ans, le spam n'est absolument pas une calamité. Le peu de spam que je reçois (2-3 par jours qui proviennent à 99% d'une vieille adresse laposte que je redirige vers mon serveur mail) est correctement classé comme spam par Amavis/spamassassin.
Ces derniers jours je me fait spammer une centaine d'alias par jour mais postfix me les bloque automatiquement car l'expéditeur est sur la liste noire de spamhaus.
Donc, le spam n'est vraiment pas un problème.
Je suis le seul utilisateur sur mon serveur.
La vrai calamité du serveur mail auto-hebergé est d'arriver à ne pas finir en spam chez google/microsoft/yahoo.
Mais avec un peu de temps et quelques personnes ayant un compte mail chez ces hébergeurs, ce problème se traite relativement facilement.
# C'est cool
Posté par J Avd . Évalué à -4.
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
# Curieux
Posté par GG (site web personnel) . Évalué à 4.
Bonjour,
je trouve ça curieux d'avoir mis SFR en whitelist, sur mon serveur c'est l'un des pire spameur, et d'ailleurs mailjet aussi, et souvent les deux sont liés…
Je n'ai pas encore regardé combien d'emails étaient rejetés (beaucoup), et c'est une bonne idée de rejeter les cas des SPF absents ou tordus parce que c'est quelque chose de normal à configurer quand on gère un serveur email.
En tout cas, ceux qui traversent les filtrages déjà en place sont peu nombreux. Je vais ajouter le contrôle des enregistrements SPF.
Merci pour ce journal
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.