Bonjour,
SPF est configuré sur mon serveur email. Sur ce point, ça marche en rejetant des emails non envoyés depuis les serveurs admis par l'enregistrement DNS du domaine envoyeur.
Néanmoins il y a un type de message qui passe encore et que je trouve ridicule. Je me demande si cela ne devrait normalement pas rentrer dans les règles de filtres SPF. Ce sont des emails envoyés depuis une adresse quelconque qui a un SPF qui passe (ou pas d'enregistrement SPF) mais dont l'expéditeur a changé le FROM. Ainsi si je regarde le Return-path, on voit une adresse email et c'est elle qui est testée pour SPF et elle passe. Par contre si le filtre regardait le FROM et testait l'enregistrement SPF du domaine du FROM (qui est une autre adresse), il rejetterait l'email.
Je me demande donc si le filtre ne devrait pas aussi vérifier cela. Qu'en pensent les admins experts du coin?
Notez que le "classique" sont des emails envoyés "apparemment" (en fait non, mais le FROM indique cela, donc le client email aussi) depuis le login "support" de mon domaine (alors que le seul support, c'est moi-même pour 4 utilisateurs), et qui en général me demande des trucs genre de mettre à jour mon compte email avec un url bidon (qui leur permettrait donc déjà de savoir que mon compte est bien actif pour me spammer mais aussi avoir mes login/mot de passe). C'est pour cela que je trouve ridicule que des emails avec un tel FROM passent (ils vont dans le dossier spam certes, mais si le filtre SPF pouvait les refuser directement, ce serait mieux).
Merci.
Forum Linux.général Améliorer la configuration SPF
29
juin
2010
# Pratique courante
Posté par Kerro . Évalué à 4.
D'abord, pas mal d'hébergeurs n'ont pas leurs dns convenablement configurés (oui bon, on n'est pas sensé s'adapter à la bêtise des autres, mais au delà d'un certain seuil ladite bêtise est une norme).
Dans mon entreprise, beaucoup d'utilisateurs ont plusieurs boîtes email, avec des noms de domaines différents.
Envoyer des emails ne se fait pas toujours via le "bon" domaine. Par exemple il est préférable d'avoir un seul prestataire ou serveur pour envoyer (car il est fiable, car il enregistre, car il fonctionne de partout, etc). Et en plus c'est simple à configurer.
Dans certains endroits il n'est pas possible d'envoyer des emails autrement qu'en passant par le relais local.
Nous avons même une raison supplémentaire: plusieurs lignes ADSL par site. Une chez Orange et une chez Free par exemple. Même les personnes qui utilisent une adresse toto@orange.fr ne peuvent passer par le SMTP d'Orange car rien ne garanti qu'ils seront sur la bonne ligne au moment de l'expédition (et orange ne permet d'accéder à leurs SMTP qu'à partir de leurs lignes).
Nous utilisons donc le SMTP d'un prestataire pour faire transiter tout nos emails.
Il y a probablement bien d'autres raisons, bonnes ou mauvaises.
[^] # Re: Pratique courante
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
donc si je comprends bien ce que tu me dis, en gros il ne *faut pas* refuser un email si le FROM ne correspond pas à la vraie adresse d'envoi ou en vérifiant l'enregistrement SPF du FROM?
Donc je suis condamné à recevoir des faux emails d'arnaque de mon propre domaine en gros (ou encore des faux emails de mes comptes Facebook/Twitter/le truc hype du moment, alors que je n'ai aucun compte chez les moindre de ces services), lesquels passent le filtre SPF car celui-ci ne se base pas sur l'adresse du FROM mais sur la vraie adresse d'envoi.
Alors bien sûr, ces emails ne passent en général pas le filtre spam ensuite, mais j'aimerais tout de même pouvoir les refuser avant tellement ce sont des faux évidents selon moi (mon domaine, donc mon adresse email, datant de nombreuses années, je reçois plus d'une centaine de spams par jour, aux alentours de 150 même. Et je parle juste de mon compte, pas du serveur).
C'est quand même vraiment un protocole ridicule le protocol email.
Si quelqu'un a des suggestions, je suis tous yeux.
Merci pour la réponse et pour d'éventuelles autres réponses.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pratique courante
Posté par Kerro . Évalué à 3.
Le FROM _est_ l'adresse d'envoi. Ton filtre SPF est sensé se baser dessus.
Que nommes-tu "vraie adresse d'envoi" ?
Ce qu'on trouve souvent, c'est toto@domain.com qui passe par smtp.orange.fr pour envoyer ses messages.
Ou toto@domain.com qui passe par checkout.banquedefrance.fr
Dans tous les cas, ton filtre SPF doit vérifier l'enregistrement SPF de domain.com (qui va te répondre "ça doit venir uniquement de smtp.domain.com" donc poubelle).
Si tu reçois des emails avec toi@ton-domaine.com alors que tu ne devrais pas, c'est que ton SPF sur ton DNS est mal renseigné (ou que tu t'es trompé dans le paramétrage de ton filtre SPF).
Ou alors je n'ai rien compris à ta question :-) Auquel cas il va te falloir expliquer posément en raison de mon grand âge.
[^] # Re: Pratique courante
Posté par PLuG . Évalué à 1.
Si le probleme est avec ton propre domaine, tu n'as qu'a lister les @IP qui ont le droit d'émettre des mails pour ton domaine, ça devrait bloquer ces mails.
[^] # Re: Pratique courante
Posté par Stéphane Gully (site web personnel) . Évalué à 1.
Par curiosité, quel prestataire ? J'ai pas mal cherché avant de me rabattre sur une solution maison SPF+DKIM...
[^] # Re: Pratique courante
Posté par Kerro . Évalué à 3.
Sinon MBII pour des raisons historiques et Oléane par paresse (là le taux de panne est impressionnant).
# Mauvaise idée
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Il faut bien prendre le MAIL FROM pour ce qu'il est : l'adresse technique d'expédition, celle où les erreurs doivent être envoyées, celle dont tu utilises <abuse@son_domaine> pour te plaindre d'un abus.
Le From, c'est l'adresse officielle de l'expéditeur, pas forcément l'endroit d'où il l'a posté.
La seule chose raisonnable à faire quand MAIL FROM != From, c'est de l'afficher dans le logiciel de messagerie. Le serveur de réception doit placer l'adresse de MAIL FROM dans un champ Return-Path, et le logiciel de messagerie doit afficher un truc du genre « Message de [From] envoyé par [MAIL FROM] ».
[^] # Re: Mauvaise idée
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
C'est pour ça qu'il se vérifie sur l'adresse MAIL FROM : si celle-ci est usurpée, il ne faut surtout pas envoyer de notification de non-réception en cas de problème.
Mais de toute façon, un serveur bien configuré n'envoie de notification de non-réception que dans de très rares cas, le reste du temps, il refuse le message à la transaction SMTP.
[^] # Re: Mauvaise idée
Posté par llaxe . Évalué à 2.
Il est surtout fait pour permettre de deviner ou de s'assurer que dans une transaction smtp, le serveur qui envoie le mail a le droit de le faire, en se basant sur le from, le helo et l'enregistrement dns de l'adresse ip.
# Je comprends pas très bien
Posté par llaxe . Évalué à 2.
Déjà, les domaines sans enregistrements spf, c'est simple, le spf n'a pas à être utilisé pour les filtrer, quelque soit le from.
L'expéditeur (=le serveur mail d'envoi) annonce un seul from pendant la transaction smtp, et chez moi c'est à ce niveau que le rejet ou le deferral sur base du spf se passe. Par contre, tu peux avoir un return-path différent du from. Mais si ton filtre spf se base là-dessus, alors que c'est dans le corps du mail je pense, ça me paraît bizarre. Autant rejeter le mail directement au niveau de la transaction, avant le data, et les seules infos dont tu disposes alors sont le helo, le from, et le rcpt-to. Chez moi ça filtre à ce niveau-là en vérifiant avec spf que l'adresse ip de la transaction est bien autorisée à envoyer avec le nom de domaine du from annoncé. Je comprends pas ton histoire de return-path.
Ensuite, si tu acceptes des mails avec indiqué dans le from ton propre domaine, soit tu durcis ta politique, ou en rejetant tous les softfails, ou en mettant -all et non pas ~all dans ton enregistrement dns, soit tu acceptes, sachant que de toute manière ils vont se retrouver dans le dossier spam. (Déjà rejette tout mail provenant d'utilisateur non-existant).
[^] # Re: Je comprends pas très bien
Posté par llaxe . Évalué à 2.
Si ton problème est de recevoir des emails depuis support@cheztoi.com, et que tu veux le régler avec spf, je pense pas que ce soit la solution, parce que le filtre spf de base est au niveau smtp, avant le data. En revanche, si tu as un filtre post smtp, style spamassassin, amavis, tu peux sûrement rajouter les règles que tu veux pour le supprimer direct avec le filtre en question. J'utilise pas (pour l'instant) de tel filtrage sur mon serveur mail, donc je sais pas comment faire pour le coup. Et vérifie aussi que dans le return-path ne sont acceptés que des utilisateurs valides.
[^] # Re: Je comprends pas très bien
Posté par Kerro . Évalué à 2.
Justement non :-)
Si _tu_ gères ton-domaine.com alors c'est toi qui décide de mettre un enregistrement SPF dans ton DNS.
Si tu sais que tu utilises n'importe quel relais, alors pas de SPF.
Si tu sais que tu utilises toujours smtp.ton-prestataire.com alors tu mets les adresses qui vont bien.
[^] # Re: Je comprends pas très bien
Posté par llaxe . Évalué à 2.
Puisqu'on peut toujours envoyer avec un return-path différent du from du corps du message, et que je ne vois pas a priori de raisons pour que cela soit toujours invalide. Ainsi les mailing-listes renvoient le message, changent donc de return-path, mais gardent le from d'origine. Ainsi, s'il s'amuse à filtrer post-smtp sur base de l'enregistrement spf, il risque de virer des messages légitimes.
Surtout spf est conçu pour fonctionner au niveau smtp je pense, pour valider les sources d'envoi à partir de leur ip, ça me surprenait donc un peu de vouloir faire un filtrage à partir des enregistrements spf sur le corps des mails.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.