Pistes de vérification des adresses d'expéditeur

[Tanguy Ortolo]

=?UTF-8?Q?v=C3=A9rification?= de =?UTF-8?Q?l=27authenticit=C3=A9?= des
messages de nouvelles, en
s'inspirant par exemple de SPF, DKIM ou DMARC
Keywords: courrier, =?UTF-8?Q?=C3=A9lectronique=2C?= nouvelles,
=?UTF-8?Q?v=C3=A9rification=2C?= adresse,
domain, DKIM, DMARC, SPF
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-13-amd64 (x86_64))

Bonjour,

Comme vous le savez sans doute, le courrier électronique a connu
quelques évolutions pour ajouter une couche de vérification partielle de
l'identité des expéditeurs, en fait une vérification du nom de domaine
de leur adresse électronique :
- Sender Policy Framework, ou SPF, pour permettre par une vérification
d'adresse IP de détecter l'usurpation de nom de domaine dans l'adresse
de l'expéditeur d'enveloppe, et lutter ainsi contre le /backscatter/ ;
- DomainKeys Identified Mail, ou DKIM, pour permettre à un serveur
de certifier par une signature cryptographique l'authenticité et le
contenu d'un message : conventionnellement, cela sert à certifier le
nom de domaine utilisé dans le champ d'expéditeur ;
- Domain-base Message Authentication, Reporting and Conformance, qui
s'appuie entre autres sur SPF et DKIM pour ajouter entre autres une
vérification, à la demande du gestionnaire d'un nom de domaine, de
la légitimité de l'utilisation de ce nom dans le champ d'expéditeur :
c'est un peu long à expliquer, le mieux est encore de lire la RFC.

iAutant que je sache, il n'existe rien de tel pour les nouvelles, mais
je m'interroge sur la possibilité de proposer quelque chose sur ce
sujet. Les nouvelles du réseau Usenet diffèrent du courrier électronique
par plusieurs points essentiels pour ce genre de question :
- il n'existe pas de notion d'enveloppe et donc pas d'expéditeur
d'enveloppe, un message a donc seulement un expéditeur indiqué dans
l'en-tête : à vrai dire, cela simplifie une possible vérification ;
- un message a bien un serveur d'injection, mais peut ensuite être
transmis par divers serveurs qui peuvent le stocker ou le transmettre
sans rien vérifier du tout, voire en l'altérant (ce qui craindrait un max,
mais c'est un autre problème) ;
- la plupart des noms de domaines utilisés par le grand public pour les
communications électroniques disposent d'un service de courrier mais
ne proposent pas de service de nouvelles associé.

L'idée d'une vérification du nom de domaine de l'adresse d'expédition
consisterait à permettre à l'administrateur d'un nom de domaine de
préciser qu'un message utilisant ce nom dans l'adresse d'expéditeur doit
être considéré comme légitime ou doit être rejeté, sous certaines
conditions :
- à la SPF : en simplifiant, un message devrait être rejeté si l'adresse
IP du serveur d'injection ne correspond pas à une liste
pré-approuvée ;
- à la DKIM : un message doit être considéré comme authentique s'il est
correctement signé par la clef du nom de domaine en question ;
- à la DMARC : un message qui ne passe ni SPF ni DKIM peut, si la
politique du nom de domaine le demande, être directement refusé.

Ce genre de vérification basée sur le nom de domaine conviendrait
surtout pour ceux qui proposent à la fois un service de courrier et un
service de nouvelles, ce qui serait en soi, déjà un progrès. Pour la
plupart des adresses électroniques, cela n'ajouterait ni ne retirerait
rien à la situation actuelle… à moins d'imaginer un système qui permette
à l'utilisateur d'une adresse électronique de préciser au monde entier
que ses messages sont censés être injectés par tel serveur ou être
signés de telle façon.

Que pensez-vous de cette idée ?

--
. o .
. . o Tanguy
o o o

[Tanguy Ortolo]

=?UTF-8?Q?v=C3=A9rification_c=C3=B4t=C3=A9?= serveur de
=?UTF-8?Q?l=27authenticit=C3=A9?= des adresses
=?UTF-8?Q?d=27exp=C3=A9diteur=2C?=

en s'inspirant par exemple de SPF, DKIM
ou DMARC

[Tanguy Ortolo]

[Jean-Pierre Kuypers]

In article (Dans l'article) <uhm8a2$q8v8$4...@herbert.ortolo.eu>, Tanguy
Ortolo <tan...@ortolo.eu> wrote (écrivait) :

> Que pensez-vous de cette idée ?

Que le groupe fr.comp.mail.serveurs convient mieux aux discussions
relatives aux serveurs de courrier que le présente groupe
fr.comp.usenet.serveurs qui est dédié aux discussions relatives aux
serveurs Usenet.

--
Jean-Pierre Kuypers

[Tanguy Ortolo]

Jean-Pierre Kuypers, 2023-10-29 19:35+0100:

> Que le groupe fr.comp.mail.serveurs convient mieux aux discussions
> relatives aux serveurs de courrier que le présente groupe
> fr.comp.usenet.serveurs qui est dédié aux discussions relatives aux
> serveurs Usenet.

Et ne convient donc pas du tout pour mon message, où je ne présente les
techniques utilisées pour le courrier électronique que pour discuter de
l'idée de faire quelque chose de semblable pour les nouvelles.

[llp]

Tanguy Ortolo <tan...@ortolo.eu> composa la prose suivante:

>Ce genre de vérification basée sur le nom de domaine conviendrait
>surtout pour ceux qui proposent à la fois un service de courrier et un
>service de nouvelles, ce qui serait en soi, déjà un progrès. Pour la
>plupart des adresses électroniques, cela n'ajouterait ni ne retirerait
>rien à la situation actuelle… à moins d'imaginer un système qui permette
>à l'utilisateur d'une adresse électronique de préciser au monde entier
>que ses messages sont censés être injectés par tel serveur ou être
>signés de telle façon.
>
>Que pensez-vous de cette idée ?

Les spams actuels sur les groupes de discussions viennent
de "googlegroups.com" la plupart du temps.
Est-ce que votre idée peu remédier à cela ?


--
Liste de serveurs offrant un accès gratuit à la hiérarchie FR.*
http://usenet.ovh/?article=faq_serveur_gratuit

Recherche d'article Usenet
http://usenet.ovh/?article=ual

[Christophe PEREZ]

Le Sun, 29 Oct 2023 18:40:17 -0000 (UTC), Tanguy Ortolo a écrit :

> Et ne convient donc pas du tout pour mon message, où je ne présente les
> techniques utilisées pour le courrier électronique que pour discuter de
> l'idée de faire quelque chose de semblable pour les nouvelles.

C'est juste la preuve qu'il n'a rien lu.
Au mieux, il a vu SPF, DKIM et DMARC et ça lui a suffit pour juger.
Déplorable.

[tTh]

Lire ---> Comprendre ---> Répondre (dans cet ordre)

--
+---------------------------------------------------------------------+
| https://wiki.interhacker.space/index.php?title=Techno-futilit%C3%A9 |
+---------------------------------------------------------------------+

[Christophe PEREZ]

Le Mon, 30 Oct 2023 04:33:08 +0100, tTh a écrit :

> Lire ---> Comprendre ---> Répondre (dans cet ordre)

Depuis pas mal d'années, c'est plutôt :

survoler | croire avoir compris | répondre n'importe quoi, quitte à tuer la
discussion en la polluant.

Et ce, dans n'importe quel ordre.

[tTh]

On 10/29/23 19:29, Tanguy Ortolo wrote:

> L'idée d'une vérification du nom de domaine de l'adresse d'expédition
> consisterait à permettre à l'administrateur d'un nom de domaine de
> préciser qu'un message utilisant ce nom dans l'adresse d'expéditeur doit
> être considéré comme légitime ou doit être rejeté, sous certaines
> conditions :
> - à la SPF : en simplifiant, un message devrait être rejeté si l'adresse
> IP du serveur d'injection ne correspond pas à une liste
> pré-approuvée ;

C'est un peu dommage pour les gens qui ont une IP dynamique
ou qui se déplacent souvent : il est impossible de construire
cette liste.

> - à la DKIM : un message doit être considéré comme authentique s'il est
> correctement signé par la clef du nom de domaine en question ;

Et là, on est à la merci du gestionnaire du domaine, ce qui
n'est pas gagné d'avance avec (exemple random :) Google.
Et je ne pense pas du tout aux utilisateurs du légitime
.invalid non plus.

tTh

[Tanguy Ortolo]

tTh, 2023-10-30 08:42+0100:

> C'est un peu dommage pour les gens qui ont une IP dynamique
> ou qui se déplacent souvent : il est impossible de construire
> cette liste.

Les gens qui maintiennent un serveur sur IP dynamique ou qui se
déplacent souvent avec leur serveur ? :-)

Comprenons-nous bien, un SPF pour les nouvelles permettrait concrètement
à l'administrateur de, disons, example.com, de préciser que les messages
avec un From: <*@example.com> injectés sur Usenet par une adresse IP qui
ne correspond pas à news.example.com devraient être rejetés.

Cela permettrait également à l'administrateur de example.net de ne rien
préciser du tout, ce qui revient à préciser que rien de tel ne doit être
fait pour les messages avec un From: <*@example.net>.

>> - à la DKIM : un message doit être considéré comme authentique s'il est
>> correctement signé par la clef du nom de domaine en question ;
>
> Et là, on est à la merci du gestionnaire du domaine, ce qui
> n'est pas gagné d'avance avec (exemple random :) Google.
> Et je ne pense pas du tout aux utilisateurs du légitime
> .invalid non plus.

Tout comme avec DKIM pour le courrier électronique. Sans rien de plus,
DKIM ne fait qu'ajouter une preuve de légitimité aux messages qui
contiennent une telle signature. Cela n'ajoute ni n'enlève rien aux
messages qui en sont dépourvus. En particulier, rien dans DKIM ne
suggère que, sous certaines conditions, des messages devraient être
rejetés.

La possibilité d'ajouter une politique de rejet de messages vient de
DMARC, qui, appliqué aux nouvelles, permettrait par exemple à
l'administrateur de example.com de préciser que les messages avec
un From: <*@example.com> qui ont été injectés par une adresse IP qui ne
correspond pas à news.example.com et qui n'ont pas de signature DKIM,
devraient être rejetés.

Cela permettrait aussi à l'administrateur de, disons, gmail.com, de ne
rien préciser du tout, ce qui revient à préciser qu'il n'a pas de
politique particulière et que les messags avec un From: <*@gmail.com> ne
devraient pas faire l'objet d'un tel traitement particulier.

[Tanguy Ortolo]

llp, 2023-10-29 22:36+0100:

> Les spams actuels sur les groupes de discussions viennent
> de "googlegroups.com" la plupart du temps.
> Est-ce que votre idée peu remédier à cela ?

Pas du tout, enfin pas vraiment.

Cela aiderait à empêcher que les spammeurs utilisent une adresse
électronique d'un nom de domaine administré par quelqu'un de bien
motivé par exemple.

Ma proposition de discussion est sans rapport avec la vague de spam
actuelle, elle vient juste d'un constat sur des nouvelles techniques
apparues ces dix dernières années dans le domaine du courrier
électronique.

[Christophe PEREZ]

Le Sun, 29 Oct 2023 18:29:22 -0000 (UTC), Tanguy Ortolo a écrit :

> Que pensez-vous de cette idée ?

Personnellement, que du bien. Mais c'est parce que je me suis très
récemment penché sur tout ça. Je connais, et c'est frais dans ma tête.

Le seul écueil que je vois, c'est que usenet se meurt et que je ne sais pas
si ça vaut un tel investissement. Mais techniquement, je suis pour.

[llp]

Tanguy Ortolo <tan...@ortolo.eu> composa la prose suivante:

>llp, 2023-10-29 22:36+0100:
>> Les spams actuels sur les groupes de discussions viennent
>> de "googlegroups.com" la plupart du temps.
>> Est-ce que votre idée peu remédier à cela ?
>
>Pas du tout, enfin pas vraiment.
>
>Cela aiderait à empêcher que les spammeurs utilisent une adresse
>électronique d'un nom de domaine administré par quelqu'un de bien
>motivé par exemple.

Je pense que ces cas sont très marginaux concernant nntp.
La quasi totalité du spam vient de vrais adresses d'un vrai domaine.
Soit d'un domaine spammeur, soit d'un compte compromis.

>Ma proposition de discussion est sans rapport avec la vague de spam
>actuelle, elle vient juste d'un constat sur des nouvelles techniques
>apparues ces dix dernières années dans le domaine du courrier
>électronique.

Ok. C'est ce qu'il me semblait.
Mais je doute de l'intérêt d'une telle mesure pour les groupes de discussions.

[Tanguy Ortolo]

llp, 2023-10-30 17:09+0100:

> Je pense que ces cas sont très marginaux concernant nntp.
> La quasi totalité du spam vient de vrais adresses d'un vrai domaine.
> Soit d'un domaine spammeur, soit d'un compte compromis.

Notez que la présence d'une couche d'authentification du nom de domaine
n'est pas totalement inintéressante dans ce contexte. Concrètement, il
est plus que pertinent de plonker un nom de domaine entier lorsqu'il est
prouvé qu'il sert à injecter du spam et que son admin ignore les
plaintes.

C'est aussi utile pour les plaintes elles-mêmes. Ainsi, si quelqu'un m'adresse
une plainte à propos d'un message avec un From: <*@ortolo.eu> mais sans
signature DKIM et avec un SPF fail, je peux répondre que je n'y suis
pour rien. Si en revanche le spam porte une signature DKIM valide, je
sais que j'ai un utilisateur qui a déconné (ou qui s'est fait pirater
son compte, mais bref, la plainte est valide).

[llp]

Tanguy Ortolo <tan...@ortolo.eu> composa la prose suivante:

>llp, 2023-10-30 17:09+0100:
>> Je pense que ces cas sont très marginaux concernant nntp.
>> La quasi totalité du spam vient de vrais adresses d'un vrai domaine.
>> Soit d'un domaine spammeur, soit d'un compte compromis.
>
>Notez que la présence d'une couche d'authentification du nom de domaine
>n'est pas totalement inintéressante dans ce contexte. Concrètement, il
>est plus que pertinent de plonker un nom de domaine entier lorsqu'il est
>prouvé qu'il sert à injecter du spam et que son admin ignore les
>plaintes.

Sur les newsgroups, la quasi totalité sur spam vient de googlegroups.
Tu penses sérieusement qu'on peut les plonker ?
Ce n'est pas la solution retenue par la plupart des admins de serveur.

>C'est aussi utile pour les plaintes elles-mêmes. Ainsi, si quelqu'un m'adresse
>une plainte à propos d'un message avec un From: <*@ortolo.eu> mais sans
>signature DKIM et avec un SPF fail, je peux répondre que je n'y suis
>pour rien. Si en revanche le spam porte une signature DKIM valide, je
>sais que j'ai un utilisateur qui a déconné (ou qui s'est fait pirater
>son compte, mais bref, la plainte est valide).

Pour les newsgroups, tu as le nom du compte qui a servi pour publier
le message. C'est le cas pour les serveurs qui utilisent une authentification
utilisateur. Ainsi si tu reçoit une plainte, quel que soit le "from", tu peux
savoir lequel de tes utilisateurs est concerné.

[Tanguy Ortolo]

llp, 2023-10-30 20:35+0100:

> Sur les newsgroups, la quasi totalité sur spam vient de googlegroups.
> Tu penses sérieusement qu'on peut les plonker ?

Ça dépend ce que tu entends par là. Techniquement, c'est certainement
faisable, au choix des administrateurs de chaque serveur.

Est-ce que c'est judicieux, ça c'est une vraie question. Je pense que le
problème doit être que pas mal de gens envoient des messages légitimes
par Google Groups, et que les plonker, c'est sans doute perdre une bonne
partie des messages, et donc en particulier se retrouver avec des fils
de discussion troués.

> Pour les newsgroups, tu as le nom du compte qui a servi pour publier
> le message. C'est le cas pour les serveurs qui utilisent une authentification
> utilisateur. Ainsi si tu reçoit une plainte, quel que soit le "from", tu peux
> savoir lequel de tes utilisateurs est concerné.

Pareil pour le courrier électronique. Mais dans les deux cas, c'est
falsifiable. Une signature DKIM, non.

[llp]

Tanguy Ortolo <tan...@ortolo.eu> composa la prose suivante:

>llp, 2023-10-30 20:35+0100:
>> Sur les newsgroups, la quasi totalité sur spam vient de googlegroups.
>> Tu penses sérieusement qu'on peut les plonker ?
>
>Ça dépend ce que tu entends par là. Techniquement, c'est certainement
>faisable, au choix des administrateurs de chaque serveur.
>
>Est-ce que c'est judicieux, ça c'est une vraie question. Je pense que le
>problème doit être que pas mal de gens envoient des messages légitimes
>par Google Groups, et que les plonker, c'est sans doute perdre une bonne
>partie des messages, et donc en particulier se retrouver avec des fils
>de discussion troués.

Tout à fait.
C'est pour cela qu'il n'est pas possible de plonker Googlegroups dans
sa totalité. On ne peut que filtrer le spam.
D'autant plus que nombre de nouveaux utilisateurs viennent via googlegroups.

>> Pour les newsgroups, tu as le nom du compte qui a servi pour publier
>> le message. C'est le cas pour les serveurs qui utilisent une authentification
>> utilisateur. Ainsi si tu reçoit une plainte, quel que soit le "from", tu peux
>> savoir lequel de tes utilisateurs est concerné.
>
>Pareil pour le courrier électronique. Mais dans les deux cas, c'est
>falsifiable. Une signature DKIM, non.

Non, pas pour les newsgroups. Le nom du compte utilisé pour poster
et mis *par* le serveur nntp. Ce n'est pas falsifiable par l'utilisateur.
Attention: je ne parle pas du "From" ou du "Sender" mais du
"posting-account" du champs "Injection-Info".

[Eric M]

Le 31/10/2023 à 10:35, llp a écrit :

> Non, pas pour les newsgroups. Le nom du compte utilisé pour poster
> et mis *par* le serveur nntp. Ce n'est pas falsifiable par l'utilisateur.
> Attention: je ne parle pas du "From" ou du "Sender" mais du
> "posting-account" du champs "Injection-Info".

Ah, le professeur LLP s'exprime :)
Et si vous créez mettons deux comptes à Zorro, comment on sait que c'est
la même personne ?

[Tanguy Ortolo]

llp, 2023-10-31 10:35+0100:

> Non, pas pour les newsgroups. Le nom du compte utilisé pour poster
> et mis *par* le serveur nntp. Ce n'est pas falsifiable par l'utilisateur.
> Attention: je ne parle pas du "From" ou du "Sender" mais du
> "posting-account" du champs "Injection-Info".

Disons que ce serait falsifiable en passant par un serveur complaisant
qui laisserait passer un message comportant déjà un champ Injection-Info
sans écraser ce dernier.

[Tanguy Ortolo]

Eric M, 2023-10-31 10:36+0100:

> Et si vous créez mettons deux comptes à Zorro, comment on sait que c'est
> la même personne ?

On ne sait pas, mais ce n'est pas le sujet.

[Eric M]

Le 31/10/2023 à 11:08, Tanguy Ortolo a écrit :

>> Et si vous créez mettons deux comptes à Zorro, comment on sait que c'est
>> la même personne ?

> On ne sait pas, mais ce n'est pas le sujet.

Avec Nemo, chaque utilisateur a un numéro et ce numéro s'affiche assez
simplement dans l'interface, mais malheureusement c'est peu lisible en
dehors de Nemo. C'est le seul exemple fiable que je connaisse, le reste
est malheureusement assez facile à forger.

[Eric M]

Le 31/10/2023 à 12:07, "M.V." a écrit :

>> Avec Nemo, chaque utilisateur a un numéro et ce numéro s'affiche assez
>> simplement dans l'interface, mais malheureusement c'est peu lisible en
>> dehors de Nemo.

> Je ne vois pas bien en quoi c'est mieux que ce que font les autres
> serveurs.
> Une même personne peut avoir 2 comptes sur Nemo, non ? Et dans ce cas,
> comment savoir que c'est la même personne puisque les 2 comptes auront
> des numéros d'identification différents.

C'est vrai, et c'est déjà arrivé en plus*, mais au moins ça identifie
une personne à coup sûr. De toute façon c'est partout pareil, même sur
Facebook vous pouvez avoir 15 comptes, après des gens se proposent qu'on
présente sa carte d'identité à chaque inscription à un réseau social,
je leur souhaite bien du courage.

*Mais je veille.

[Eric M]

Le 31/10/2023 à 12:07, "M.V." a écrit :

>> Avec Nemo, chaque utilisateur a un numéro et ce numéro s'affiche assez
>> simplement dans l'interface, mais malheureusement c'est peu lisible en
>> dehors de Nemo.

> Je ne vois pas bien en quoi c'est mieux que ce que font les autres
> serveurs.
> Une même personne peut avoir 2 comptes sur Nemo, non ? Et dans ce cas,
> comment savoir que c'est la même personne puisque les 2 comptes auront
> des numéros d'identification différents.

C'est vrai, et c'est déjà arrivé en plus*, mais au moins ça identifie
une personne à coup sûr. De toute façon c'est partout pareil, même sur

Facebook vous pouvez avoir 15 comptes, après des gens proposent qu'on

[llp]

"M.V." <m...@gmail.invalid> composa la prose suivante:

>Dans le message <tqLLZMCvcev3v1xhxvtqGI4xuRY@jntp>, Eric M a écrit le 31
>octobre 2023 à 11 h 54 :

>
>>>> Et si vous créez mettons deux comptes à Zorro, comment on sait que c'est
>>>> la même personne ?
>>

>> Avec Nemo, chaque utilisateur a un numéro et ce numéro s'affiche assez
>> simplement dans l'interface, mais malheureusement c'est peu lisible en
>> dehors de Nemo.
>

>Je ne vois pas bien en quoi c'est mieux que ce que font les autres
>serveurs.
>Une même personne peut avoir 2 comptes sur Nemo, non ? Et dans ce cas,
>comment savoir que c'est la même personne puisque les 2 comptes auront
>des numéros d'identification différents.

Tout à fait.
Eric le sait très bien.

[llp]

Tanguy Ortolo <tan...@ortolo.eu> composa la prose suivante:

Pas sur que cela soit possible avec inn.
En plus j'en vois mal l'intérêt.

[llp]

Eric M <conano...@gmail.com> composa la prose suivante:

>Le 31/10/2023 à 12:07, "M.V." a écrit :
>
>>> Avec Nemo, chaque utilisateur a un numéro et ce numéro s'affiche assez
>>> simplement dans l'interface, mais malheureusement c'est peu lisible en
>>> dehors de Nemo.
>
>> Je ne vois pas bien en quoi c'est mieux que ce que font les autres
>> serveurs.
>> Une même personne peut avoir 2 comptes sur Nemo, non ? Et dans ce cas,
>> comment savoir que c'est la même personne puisque les 2 comptes auront
>> des numéros d'identification différents.
>
>C'est vrai, et c'est déjà arrivé en plus*, mais au moins ça identifie
>une personne à coup sûr.

Le compte présent dans injection info aussi.
Et en plus c'est standard avec inn.

>*Mais je veille.

On est rassuré: Eric, le plus grand trolleur de cette hiérarchie, vielle :-)