Merci pour ton message.
Le SPF tout seul ne protège en effet pas contre l'usurpation car il ne s'intéresse pas au FROM (ce que vous voyez dans votre MUA) mais au MAIL FROM qui devient le return-path.
Mais l'alignement du domaine utilisé par le SPF avec le domaine du FROM imposé par DMARC (qui dépend donc du SPF) protège, dans une certaine mesure, contre l'usurpation. Je dis "dans une certaine mesure" car quand le SPF passe ET qu'il est aligné avec le domaine du FROM (au sens DMARC), on a vérifié que l'email provient bien d'une source autorisée à envoyer un mail au nom du domaine du FROM mais on ne garantit pas que le contenu du mail n'a pas été modifié. Le DKIM permet de se protéger contre la modification du mail durant le transport.
C'est précisément toutes ces informations que j'ai regroupées dans la série d'articles.
Merci pour ton retour. Je constate en effet que le site fait avec IA passe mais pas les commentaires. Je vais donc arrêter d'utiliser l'IA pour les messages et je présente mes excuses si cela a blessé, mon but est de parler de protocole de mail pour améliorer les 9 articles.
"C'est assez confus tout cela." => C'est vrai que c'est un peu technique et qu'on est dans les détails, désolé.
Sur le fond, on est d'accord avec @JJD et il l'a dit "Le SPF du domaine initial, example.com, ne sert alors absolument à rien." (dans ce cas précis, n'en faisons pas une généralité, le SPF c'est bien utile).
Ce que j'ai précisé, c'est ma formulation et les données que j'apporte correspondent à un vrai rapport DMARC d'un domaine que j'administre. J'ai bien eu un échange avec le support Mailjet qui confirme, ce n'est pas du texte inventé par IA.
Et oui j'utilise l'IA qui écrit mieux que moi, mais ça reste mes idées, mes réflexions, mes apprentissages et enfin mes vérifications.
Oui, mis à part celui-là, ce sont tous des messages généré par IA.
Sur mon site également, je ne le cache pas, c'est marqué sur toutes mes pages.
Est-ce que ça discrédite le contenu ?
Je ne pense pas, ce sont mes idées, mes relectures, mes vérifications et je me sers de ces connaissances régulièrement.
Je passe beaucoup de temps à produire ce contenu (malgré l'IA) en dehors des traductions en anglais et je le dis clairement sur chaque page.
J'aime la syntaxe/la forme produite par l'IA, je suis dysorthographique. Le fond c'est le mien. C'est bien moi qui ai choisi ce sujet sous l'angle de la personne qui a un domaine à paramétrer pour l'antispoofing email, moi qui ai choisi la pédagogie des articles, moi qui ai vérifié, relu et paramétré une dizaine de domaines et je continue.
J'ai beaucoup appris, j'aime voir l'IA comme un extracteur de connaissance.
Au départ ce site c'est une note sur Joplin pour m'y référer, puis j'ai fait le site pour partager avec des collègues et des proches. J'ai franchi le cap en créant mon compte sur ce site et en publiant. Si mon contenu dérange et qu'il y a un consensus je veux bien supprimer mon compte. Je ne veux embêter personne. Je pense que mon contenu apporte une valeur et c'est pour ça que je l'ai partager. Ce n'est pas du Slop.
J'espère que tu ne vas pas me discréditer parce que j'utilise un outil pour la forme et pour apprendre.
Enfin, je préfère relire les messages que j'ai généré et travaillé avec l'IA que ce message.
Merci, et tu as raison : avec SRS, le forwarder réécrit l'enveloppe sur son propre domaine, donc SPF valide contre ce domaine et passe indépendamment du SPF du domaine d'origine. Sur la validation SPF, on est parfaitement d'accord.
Le malentendu vient de ma formulation : quand j'écrivais « SPF casse » au transfert, je voulais dire « l'alignement SPF casse » (au sens DMARC), pas la validation. Je reconnais volontiers que ça prêtait à confusion.
DMARC exige que le domaine authentifié par SPF soit aligné avec le domaine du From:. Après un transfert, que l'enveloppe soit réécrite en SRS (SPF passe, mais sur le domaine du forwarder) ou conservée (SPF échoue), le domaine SPF authentifié n'est jamais celui du From:. En conséquence, l'alignement SPF casse. C'est DKIM qui « porte » l'authentification du From: à travers le transfert (sa signature voyage avec le message).
Et je le vois dans mes propres rapports DMARC sur tous les domaines que je gère. Sur un des domaines qui envoie beaucoup de mails (~17 000 mails/semaine), les sources en transfert (Google, Outlook, Orange, Proton, Gandi...) ressortent à SPF aligné 0 % / DKIM aligné 100 %, et DMARC passe quand même à 100 % grâce à DKIM. C'est exactement le comportement attendu.
(Et merci d'avoir confirmé le point Mailjet : le SPF du domaine d'origine ne sert à rien pour ces envois : on est d'accord.)
Merci pour ton retour ! On est d'accord sur l'essentiel : SPF est indispensable, et ton explication (-all, autorisation des IP émettrices) me semble exacte.
Une précision, parce que ma phrase ne dit pas que « SPF est cosmétique » : elle porte sur l'include:spf.mailjet.com qu'on te demande d'ajouter au SPF de ton domaine (celui du From:). Le point est là : le SPF récupéré et évalué est celui du domaine du return-path (l'enveloppe), pas celui du From:. Or, pour un ESP qui gère les bounces (ex: Mailjet), le return-path est le domaine de l'ESP (ex: bnc3.mailjet.com), ou un return-path personnalisé bnc3.mondomaine.fr qui pointe (CNAME) vers le SPF de Mailjet. Le SPF du domaine du From n'est donc jamais consulté pour ces envois : d'où le côté cosmétique de cet include-là (le support Mailjet me l'a confirmé par écrit).
À l'inverse, quand c'est l'hébergeur de boîtes qui émet depuis @mondomaine.fr (messagerie « normale »), le return-path est bien @mondomaine.fr : là son SPF est consulté, et les includes correspondants (Proton, Google, OVH...) sont indispensables. C'est donc uniquement l'include Mailjet qui est inutile, parce que Mailjet n'utilise jamais le domaine du From comme return-path.
Bref, on est bien d'accord sur SPF ; la phrase visait ce cas précis.
Sur le -all : Comme le transfert casse SPF (l'enveloppe est conservée, mais l'IP du relais change), un receveur ne peut pas en faire un rejet absolu sans jeter du courrier légitime. C'est justement pour ça que SPF est aujourd'hui consommé via DMARC, en tandem avec DKIM (qui, lui, survit au transfert) : si SPF casse mais que DKIM est aligné, DMARC passe. SPF devient donc un signal parmi d'autres plutôt qu'un verrou. En revanche, sur le fait que ce soit « de moins en moins respecté » qu'avant ou que des messages disparaissent, je n'ai pas d'observation de première main, je te fais confiance là-dessus.
[^] # Re: SPF
Posté par Yanal-Yves . En réponse au journal Antispoofing e-mail (SPF, DKIM, DMARC, BIMI) : la synthèse que j'aurais aimé trouver. Évalué à -5 (+0/-4).
Merci pour ton message.
Le SPF tout seul ne protège en effet pas contre l'usurpation car il ne s'intéresse pas au
FROM(ce que vous voyez dans votre MUA) mais auMAIL FROMqui devient lereturn-path.Mais l'alignement du domaine utilisé par le SPF avec le domaine du
FROMimposé par DMARC (qui dépend donc du SPF) protège, dans une certaine mesure, contre l'usurpation. Je dis "dans une certaine mesure" car quand le SPF passe ET qu'il est aligné avec le domaine duFROM(au sens DMARC), on a vérifié que l'email provient bien d'une source autorisée à envoyer un mail au nom du domaine duFROMmais on ne garantit pas que le contenu du mail n'a pas été modifié. Le DKIM permet de se protéger contre la modification du mail durant le transport.C'est précisément toutes ces informations que j'ai regroupées dans la série d'articles.
Yanal-Yves
[^] # Re: SPF
Posté par Yanal-Yves . En réponse au journal Antispoofing e-mail (SPF, DKIM, DMARC, BIMI) : la synthèse que j'aurais aimé trouver. Évalué à -4 (+2/-6).
Merci pour ton retour. Je constate en effet que le site fait avec IA passe mais pas les commentaires. Je vais donc arrêter d'utiliser l'IA pour les messages et je présente mes excuses si cela a blessé, mon but est de parler de protocole de mail pour améliorer les 9 articles.
Yanal-Yves
[^] # Re: SPF
Posté par Yanal-Yves . En réponse au journal Antispoofing e-mail (SPF, DKIM, DMARC, BIMI) : la synthèse que j'aurais aimé trouver. Évalué à -5 (+0/-5).
"C'est assez confus tout cela." => C'est vrai que c'est un peu technique et qu'on est dans les détails, désolé.
Sur le fond, on est d'accord avec @JJD et il l'a dit "Le SPF du domaine initial, example.com, ne sert alors absolument à rien." (dans ce cas précis, n'en faisons pas une généralité, le SPF c'est bien utile).
Ce que j'ai précisé, c'est ma formulation et les données que j'apporte correspondent à un vrai rapport DMARC d'un domaine que j'administre. J'ai bien eu un échange avec le support Mailjet qui confirme, ce n'est pas du texte inventé par IA.
Et oui j'utilise l'IA qui écrit mieux que moi, mais ça reste mes idées, mes réflexions, mes apprentissages et enfin mes vérifications.
Yanal-Yves
[^] # Re: SPF
Posté par Yanal-Yves . En réponse au journal Antispoofing e-mail (SPF, DKIM, DMARC, BIMI) : la synthèse que j'aurais aimé trouver. Évalué à -6 (+0/-6).
Salut,
Oui, mis à part celui-là, ce sont tous des messages généré par IA.
Sur mon site également, je ne le cache pas, c'est marqué sur toutes mes pages.
Est-ce que ça discrédite le contenu ?
Je ne pense pas, ce sont mes idées, mes relectures, mes vérifications et je me sers de ces connaissances régulièrement.
Je passe beaucoup de temps à produire ce contenu (malgré l'IA) en dehors des traductions en anglais et je le dis clairement sur chaque page.
J'aime la syntaxe/la forme produite par l'IA, je suis dysorthographique. Le fond c'est le mien. C'est bien moi qui ai choisi ce sujet sous l'angle de la personne qui a un domaine à paramétrer pour l'antispoofing email, moi qui ai choisi la pédagogie des articles, moi qui ai vérifié, relu et paramétré une dizaine de domaines et je continue.
J'ai beaucoup appris, j'aime voir l'IA comme un extracteur de connaissance.
Au départ ce site c'est une note sur Joplin pour m'y référer, puis j'ai fait le site pour partager avec des collègues et des proches. J'ai franchi le cap en créant mon compte sur ce site et en publiant. Si mon contenu dérange et qu'il y a un consensus je veux bien supprimer mon compte. Je ne veux embêter personne. Je pense que mon contenu apporte une valeur et c'est pour ça que je l'ai partager. Ce n'est pas du Slop.
J'espère que tu ne vas pas me discréditer parce que j'utilise un outil pour la forme et pour apprendre.
Enfin, je préfère relire les messages que j'ai généré et travaillé avec l'IA que ce message.
Yanal-Yves
[^] # Re: SPF
Posté par Yanal-Yves . En réponse au journal Antispoofing e-mail (SPF, DKIM, DMARC, BIMI) : la synthèse que j'aurais aimé trouver. Évalué à -2 (+2/-4).
Merci, et tu as raison : avec SRS, le forwarder réécrit l'enveloppe sur son propre domaine, donc SPF valide contre ce domaine et passe indépendamment du SPF du domaine d'origine. Sur la validation SPF, on est parfaitement d'accord.
Le malentendu vient de ma formulation : quand j'écrivais « SPF casse » au transfert, je voulais dire « l'alignement SPF casse » (au sens DMARC), pas la validation. Je reconnais volontiers que ça prêtait à confusion.
DMARC exige que le domaine authentifié par SPF soit aligné avec le domaine du
From:. Après un transfert, que l'enveloppe soit réécrite en SRS (SPF passe, mais sur le domaine du forwarder) ou conservée (SPF échoue), le domaine SPF authentifié n'est jamais celui duFrom:. En conséquence, l'alignement SPF casse. C'est DKIM qui « porte » l'authentification duFrom:à travers le transfert (sa signature voyage avec le message).Je détaille justement ça (SRS, et la distinction validation SPF vs alignement SPF) dans l'article SPF : https://yanal.fargialla.com/antispoofing-e-mail/04-spf-sender-policy-framework/#le-spf-ne-résiste-pas-au-forward-de-mail
Et je le vois dans mes propres rapports DMARC sur tous les domaines que je gère. Sur un des domaines qui envoie beaucoup de mails (~17 000 mails/semaine), les sources en transfert (Google, Outlook, Orange, Proton, Gandi...) ressortent à SPF aligné 0 % / DKIM aligné 100 %, et DMARC passe quand même à 100 % grâce à DKIM. C'est exactement le comportement attendu.
(Et merci d'avoir confirmé le point Mailjet : le SPF du domaine d'origine ne sert à rien pour ces envois : on est d'accord.)
Yanal-Yves
[^] # Re: SPF
Posté par Yanal-Yves . En réponse au journal Antispoofing e-mail (SPF, DKIM, DMARC, BIMI) : la synthèse que j'aurais aimé trouver. Évalué à 2 (+7/-5).
Merci pour ton retour ! On est d'accord sur l'essentiel : SPF est indispensable, et ton explication (-all, autorisation des IP émettrices) me semble exacte.
Une précision, parce que ma phrase ne dit pas que « SPF est cosmétique » : elle porte sur l'include:spf.mailjet.com qu'on te demande d'ajouter au SPF de ton domaine (celui du From:). Le point est là : le SPF récupéré et évalué est celui du domaine du return-path (l'enveloppe), pas celui du From:. Or, pour un ESP qui gère les bounces (ex: Mailjet), le return-path est le domaine de l'ESP (ex: bnc3.mailjet.com), ou un return-path personnalisé bnc3.mondomaine.fr qui pointe (CNAME) vers le SPF de Mailjet. Le SPF du domaine du From n'est donc jamais consulté pour ces envois : d'où le côté cosmétique de cet include-là (le support Mailjet me l'a confirmé par écrit).
À l'inverse, quand c'est l'hébergeur de boîtes qui émet depuis @mondomaine.fr (messagerie « normale »), le return-path est bien @mondomaine.fr : là son SPF est consulté, et les includes correspondants (Proton, Google, OVH...) sont indispensables. C'est donc uniquement l'include Mailjet qui est inutile, parce que Mailjet n'utilise jamais le domaine du From comme return-path.
Bref, on est bien d'accord sur SPF ; la phrase visait ce cas précis.
Sur le -all : Comme le transfert casse SPF (l'enveloppe est conservée, mais l'IP du relais change), un receveur ne peut pas en faire un rejet absolu sans jeter du courrier légitime. C'est justement pour ça que SPF est aujourd'hui consommé via DMARC, en tandem avec DKIM (qui, lui, survit au transfert) : si SPF casse mais que DKIM est aligné, DMARC passe. SPF devient donc un signal parmi d'autres plutôt qu'un verrou. En revanche, sur le fait que ce soit « de moins en moins respecté » qu'avant ou que des messages disparaissent, je n'ai pas d'observation de première main, je te fais confiance là-dessus.
Yanal-Yves