(Courriels de diversion: <cupidement@servie-samouraïs.com> <speciales@avalerent-desengagerent.com> <deleguerons@contrebassiste-suralimentees.com> <pollueriez@inflige-rallongea.com> <pendront@devorait-viole.com> <huerait@envie-jaugeons.com> <maritaux@imputent-futurs.com> <non-residant@speculent-doit.com> <ramenerions@assaillent-retractile.com> <dedommagerent@aventurent-satiriser.com> )


Le 18 Août, Yannick Jestin écrit :

>   Ceci dit, je veux bien être briefé pour les aspect chasse au spammer. Marc ?

  Le principe de base est de faire cesser l'abus, ou de faire en sorte
qu'il ne se reproduise plus. Si la manière polie et conciliante ne
fonctionne pas, alors il faut soumettre l'adresse de l'émetteur à une
liste de blocage (qu'utilise savage), suivant la procédure décrite à
<URL:http://maps.vix.com/rbl/reporting.html>.

  Mais pour pouvoir expliquer aux gens que ce qu'ils font est mal,
encore faut-il pouvoir les identifier (ou identifier leur fournisseur
de courrier).

I. Le transport du courrier.

  Si je regarde l'en-tête de ton message, je vois (j'ai viré les champs
qui ne m'intéressent pas) :

Received: from mipnet.UUCP (uucp@localhost) by zapata.internal.le-pic.org (8.8.8/8.7.3) with UUCP id WAA00542 for zapata!thirion; Fri, 18 Aug 2000 22:32:33 +0200Received: from savage.iut-blagnac.fr (savage.iut-blagnac.fr [193.54.227.231])
	by mipnet.mipnet.fr (8.9.3/8.9.3) with SMTP id PAA26587
	for <thirion@mipnet.fr>; Fri, 18 Aug 2000 15:52:44 +0200 (MET DST)Received: (qmail 15173 invoked by alias); 18 Aug 2000 13:56:41 -0000
Received: (qmail 15166 invoked from network); 18 Aug 2000 13:56:40 -0000
Received: from fw.tls.cena.fr (HELO fw.cena.fr) (195.83.98.200)
  by savage.iut-blagnac.fr with SMTP; 18 Aug 2000 13:56:40 -0000
Received: by fw.cena.fr; (5.65v4.0/1.3/10May95) id AA28784; Fri, 18 Aug 2000 15:56:39 +0200
Received: from somewhere by smtpxd
Received: from somewhere by smtpxd

  Chaque agent de transport a ajouté en tête une ligne commençant par
« Received: » qui permet de l'identifier.

  Les deux premières lignes correspondent au passage chez mon fournisseur
de courrier (« Received ... by mipnet.mipnet.fr ») et sur ma machine perso
(« Received ... by zapata »).

  En descendant dans les lignes « Received: », on peut retracer le chemin
qu'a suivi le message.

  Ceci est la théorie. En pratique, celui qui contrôle la machine qui
transporte le courrier peut très bien ne pas lui faire écrire la ligne
« Received: » correspondante, ou lui faire indiquer des choses fausses
(ou inutiles pour notre propos, comme par exemple les deux dernières
lignes).

  Dans la liste des agents de transports, il faut donc déterminer le
dernier auquel tu peux faire confiance. Pour ce qui nous occupe, c'est
savage.

  Savage nous dit qu'elle a reçu ton courrier d'une machine utilisant
l'adresse IP 195.83.98.200 (dont les DNS inverses disent qu'elle est
nommée fw.tls.cena.fr) et se présentant au cours du dialogue SMTP sous
le nom de fw.cena.fr. Le courrier a été reçu le 18 Août à 15h56 (savage
indique l'heure UTC).

  Tout cela est-il bien cohérent ? Voyons voir...

$ host fw.tls.cena.fr          
fw.tls.cena.fr          A       195.83.98.200
$ host 195.83.98.200 
Name: fw.tls.cena.fr
Address: 195.83.98.200

  Ça correspond (ce qui n'est guère étonnant, puisque je viens de vérifier
des informations déjà fournies par savage ; tu peux utiliser nslookup à la
place de host).

II. Trouver l'expéditeur immédiat.

  Qui sont les gens derrière cena.fr ? C'est un domaine .fr, donc ils sont
enregistré dans les bases whois de nic.fr (suivant le client whois, la syntaxe
peut changer ; de plus, certains nics ne permettent pas la consultation par
whois ; il faut aller sur leur site ouaibe www.nic.deuxLettres) :

$ whois -h whois.nic.fr cena.fr

Rights restricted by copyright.
See http://www.ripe.net/db/dbcopyright.html
Tous droits reserves par copyright.
Voir http://www.nic.fr/info/whois/dbcopyright.html


domain:      cena.fr
descr:       Centre d'Etudes de la Navigation Aerienne
descr:       7 Avenue Edouard Belin
descr:       BP 4005
descr:       TOULOUSE 31055
admin-c:     DCDV1-RIPE
tech-c:      BK970-RIPE
tech-c:      NC266-RIPE
zone-c:      NFC1-RIPE
nserver:     vitre.cena.fr 195.83.98.201
nserver:     hilar.cena.fr 195.83.98.1
mnt-by:      FR-NIC-MNT
mnt-lower:   FR-NIC-MNT
changed:     ripe-dbm-updates@nic.fr 19990430source:      RIPE

role:        NIC France Contact
address:     AFNIC (NIC France)
address:     Domaine de Voluceau B.P. 105
address:     F-78153 Le Chesnay CEDEX, France
phone:       +33 1 39 63 56 16
fax-no:      +33 1 39 63 55 34
e-mail:      tech@nic.frtrouble:     Information: http://www.nic.fr/
trouble:     Questions:  mailto:nic@nic.frtrouble:     Spam: mailto:abuse@nic.frtrouble:     Test: mailto:ping@nic.fradmin-c:     AR41
tech-c:      AR41
tech-c:      PL12-RIPE
tech-c:      JP1110-RIPE
tech-c:      EM634-RIPE
tech-c:      MS1887-RIPE
tech-c:      VL229-RIPE
tech-c:      PR1249-RIPE
tech-c:      PV827-RIPE
tech-c:      GO661-RIPE
tech-c:      FT1632-RIPE
tech-c:      PB9432-RIPE
nic-hdl:     NFC1-RIPE
mnt-by:      FR-NIC-MNT
changed:     ripe-dbm-updates@nic.fr 20000803source:      RIPE

person:      Dominique COLIN DE VERDIERE
address:     CENA-TOULOUSE - Centre d'Etude de la Navigation Aerienne
address:     7, Avenue Edouard Belinn - BP 4005
address:     31055 TOULOUSE Cedex
phone:       +33 5 62 25 95 00
fax-no:      +33 5 62 25 95 40
nic-hdl:     DCDV1-RIPE
changed:     rensvp@renater.fr 19980909source:      RIPE

person:      Bruno KRINER
address:     CENA-TOULOUSE - Centre d'Etude de la Navigation Aerienne
address:     7, Avenue Edouard Belinn - BP 4005
address:     31055 TOULOUSE Cedex
phone:       +33 5 62 25 95 00
fax-no:      +33 5 62 25 95 99
e-mail:      kriner@cenatls.cena.dgac.frnic-hdl:     BK970-RIPE
changed:     rensvp@renater.fr 19980909source:      RIPE

person:      Nicolas COURTEL
address:     CENA-TOULOUSE - Centre d'Etude de la Navigation Aerienne
address:     7, Avenue Edouard Belinn - BP 4005
address:     31055 TOULOUSE Cedex
phone:       +33 5 62 25 95 00
fax-no:      +33 5 62 25 95 99
e-mail:      courtel@cenatls.cena.dgac.frnic-hdl:     NC266-RIPE
changed:     rensvp@renater.fr 19980909source:      RIPE

  Qui a attribué les adresses IP aux gens qui possèdent la machine
195.83.98.200 ? Comme la machine semble se situer en Europe, adressons-
nous au RIPE (pour les autres régions du mondes, voir les liens sur le
site ouaibe <URL:http://www.ripe.net/>).

$ whois -h whois.ripe.net 195.83.98.200

% Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html

inetnum:     195.83.98.0 - 195.83.98.255
netname:     FR-RENATER
descr:       RENATER:
country:     FR
admin-c:     DV321-RIPE
tech-c:      FS65-RIPE
tech-c:      WM153-RIPE
status:      ASSIGNED PA
mnt-by:      AS1717-MNT
changed:     rensvp@renater.fr 19990908source:      RIPE

route:       195.83.0.0/16
descr:       RENATER
descr:       ENSAM - 151, Boulevard de l'hopital,
descr:       75013 Paris
descr:       FRANCE
origin:      AS2200
mnt-by:      RENATER-MNT
changed:     RenSVP@Renater.fr 19991008source:      RIPE

person:      Dany VANDROMME
address:     GIP RENATER
address:     ENSAM
address:     151, Boulevard de l'hopital, 75013 Paris
address:     France
phone:       +33 1 53 94 20 30
fax-no:      +33 1 53 94 20 31
e-mail:      Dany.Vandromme@Renater.frnic-hdl:     DV321-RIPE
changed:     RenSVP@Renater.fr 19991018source:      RIPE

person:      Franck SIMON
address:     GIP RENATER
address:     ENSAM
address:     151, Boulevard de l'hopital, 75013 Paris
address:     France
phone:       +33 1 53 94 20 43
fax-no:      +33 1 53 94 20 41
e-mail:      Franck.Simon@Renater.frnic-hdl:     FS65-RIPE
mnt-by:      RENATER-MNT
changed:     RenSVP@Renater.fr 19991018source:      RIPE

person:      Willy MISCHLER
address:     GIP RENATER
address:     ENSAM
address:     151, Boulevard de l'hopital, 75013 Paris
address:     France
phone:       +33 1 53 94 20 46
fax-no:      +33 1 53 94 20 41
e-mail:      Willy.Mischler@Renater.frnic-hdl:     WM153-RIPE
mnt-by:      RENATER-MNT
changed:     RenSVP@Renater.fr 19991018source:      RIPE

  Maintenant, dans ce cas simple, j'ai cerné d'où vient le message et les
différents intervenants. Ceci reste quand même de haut niveau : il pourrait
y avoir des intermédiaires. Pour compléter, je fais un traceroute vers la
machine 195.83.98.200. J'aurai ainsi une vue plus fine de sa connectivité :

$ traceroute 195.83.98.200
traceroute to 195.83.98.200 (195.83.98.200), 30 hops max, 40 byte packets
 1  toulouse-1-4-254.dial.proxad.net (213.228.4.254)  185.187 ms  207.835 ms  149.131 ms
 2  marseille1.routers.proxad.net (212.27.32.230)  158.937 ms  148.584 ms  149.298 ms
 3  212.27.32.254 (212.27.32.254)  159.038 ms  148.592 ms  159.233 ms
 4  paris11-2-a1.routers.proxad.net (212.27.32.225)  179.065 ms  158.669 ms  219.277 ms
 5  sfinx.routers.proxad.net (213.228.3.26)  198.848 ms  168.691 ms  169.3 ms
 6  ri-renater.gix-paris.ft.net (194.68.129.34)  188.994 ms  168.696 ms  179.266 ms
 7  nio-i.cssi.renater.fr (193.51.206.57)  179.028 ms  288.599 ms  259.435 ms
 8  nio-n1.cssi.renater.fr (193.51.206.9)  278.695 ms  178.598 ms  249.26 ms
 9  toulouse.cssi.renater.fr (195.220.99.134)  439.326 ms  178.442 ms  179.286 ms
10  NRCP-toulouse.cssi.renater.fr (195.220.99.142)  178.727 ms  298.645 ms  209.408 ms
11  * * *
12  octares2.remip.ft.net (193.48.63.250)  190.14 ms  189.106 ms  469.921 ms
13  cena-toulouse.remip.ft.net (193.48.63.34)  309.426 ms  209.256 ms  319.657 ms
14  fw.tls.cena.fr (195.83.98.200)  203.322 ms  239.182 ms  179.492 ms

  (L'Internet, c'est comme la SNCF : le plus court chemin passe par Paris).

  Je vois que fw.tls.cena.fr est relié à l'Internet par des machines 
appartenant à des gens possédant le domaine ft.net (entre autres, car il
peut y avoir d'autres connexions).

  Il faut voir qui sont ces gens. Comme c'est un .net (et il en va de même
pour .org et .com), il faut d'abord déterminer qui est le greffier (registrar)
pour ce domaine en interrogeant whois.internic.net :

$ whois ft.net     

Whois Server Version 1.1

Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: FT.NET
   Registrar: NETWORK SOLUTIONS, INC.
   Whois Server: whois.networksolutions.com
   Referral URL: www.networksolutions.com
   Name Server: JANE.FT.NET
   Name Server: TARZAN.FT.NET
   Updated Date: 07-aug-2000


>>> Last update of whois database: Sun, 20 Aug 00 04:37:15 EDT <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.

  Je sais maintenant à qui demander les infos :

$ whois -h whois.networksolutions.com ft.net    
The Data in Network Solutions' WHOIS database is provided by Network
Solutions for information purposes, and to assist persons in obtaining
information about or related to a domain name registration record.
Network Solutions does not guarantee its accuracy.  By submitting a
WHOIS query, you agree that you will use this Data only for lawful
purposes and that, under no circumstances will you use this Data to:
(1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail
(spam); or  (2) enable high volume, automated, electronic processes
that apply to Network Solutions (or its systems).  Network Solutions
reserves the right to modify these terms at any time.  By submitting
this query, you agree to abide by this policy.

Registrant:
France Telecom (FT-DOM)
   DRN/DPS
   CPRI St Amand
   CSC Transrel
   9, rue de NANTEUIL
   75731 PARIS  Cedex 15
   FRANCE

   Domain Name: FT.NET

   Administrative Contact:
      Gava, Bruno  (BG68)  cdn@CEDRE.FRANCE-TELECOM.FR      France Telecom
      CPRI St Amand
      9, rue de NANTEUIL
      75731 PARIS  Cedex 15
      FR
      33 1 40 45 56 26
   Technical Contact, Zone Contact:
      Chaillot, Christophe  (CC102)  christophe.chaillot@FRANCETELECOM.FR      France Telecom FTRSI/DPI
      246, rue de Bercy
      Paris Cedex 12
      75584
      FR
      +33 1 43 42 68 87 (FAX) +33 1 43 42 62 67

   Record last updated on 23-Mar-1998.
   Record expires on 09-Aug-2000.
   Record created on 08-Aug-1994.
   Database last updated on 19-Aug-2000 20:43:28 EDT.

   Domain servers in listed order:

   TARZAN.FT.NET                193.48.69.3
   JANE.FT.NET                  193.54.137.9

  Là, je crois que j'ai assez d'infos. Le message vient d'une organisation
toulousaine appelée « Centre d'Etudes de la Navigation Aerienne ». Sa
connexion Internet est fournie (au moins en partie) par une organisation
parisienne appelée « France Telecom » qui est connectée elle-même (au
moins en partie) par une autre organisation parisienne appelée
« RENATER ».

  Notons au passage, que je ne peux pas déduire de ces données l'existence
de REMIP.

  Voilà qui me donne plusieurs pistes pour me plaindre de ton message.

III. Se plaindre.

  En premier, je tenterai le plus évident : postmaster@fw.tls.cena.fr, et,si cela ne répond pas, postmaster@fw.cena.fr (puisque la machine se présenteainsi). C'est-à-dire que je vais tenter de m'adresser au responsable local
du courrier.

  Si cela ne fonctionne pas (par exemple le responsable local est complice,
ou il redirige ses courriers vers /dev/null), je vais m'adresser aux
contacts techniques du domaine cena.fr (en général, on ne s'intéressera
pas aux contacts administratifs ou de facturation) :
kriner@cenatls.cena.dgac.fr et courtel@cenatls.cena.dgac.fr. 
  Si je n'obtiens toujours pas de réponse satisfaisante, il va me falloir
m'adresser à quelqu'un en dehors de l'organisation qui maîtrise le
domaine cena.fr.

  Là, j'ai le choix entre les gens qui on délégué la zone cena.fr
(c'est-à-dire ceux qui possèdent le domaine .fr) et ceux qui fournissent
(au moins en partie) la connexion Internet (« France Telecom » d'abord,
puis en désespoir de cause « RENATER »).

  Il faut inclure le message ligitieux dans la plainte (avec _tous_ les
en-têtes) et expliquer pourquoi vous n'êtes pas content d'avoir reçu le
message, et ce que vous attendez de la personne à laquelle vous vous
adressez (genre : expliquer à l'émetteur pourquoi ce qu'il a fait n'est
pas bien, fermer le compte, etc).

  En tout état de cause, il vaut mieux être poli, puisqu'il y a peu
de chances que la personne à laquelle vous vous adressez soit complice
du méfait.

IV. Le relai.

  J'ai supposé, dans ce qui précède, que la machine qui a paasé le message
à savage est une machine dont l'émetteur peut légitiment se servir (et donc
que l'organisation qui la possède peut agir directement sur l'émetteur).

  De nos jours, ce sera assez fréquent, les serveurs de courrier étant
majoritairement configurés pour n'accepter que des courrier venant, ou
à destination, de l'organisation (ou à destination des organisations pour
lesquelles ils servent de serveur de secours)

  Il peut néanmoins arriver que des serveurs de courrier soient configurés
de manière inadéquate (parfois transitoiremnt à la suite d'une erreur) et
qu'ils acceptent de retransmettre du courrier originaire de tiers et destinés
à des tiers.

  Deux problèmes se posent alors :
  - il faut avertir l'administrateur de la machine qu'il relaye n'importe
    quel courrier, et qu'il faut que cela cesse :
  - il faut déterminer si cela vaut le coup de passer à la ligne « Received: »
    suivante pour identifier l'émetteur.

  Sur le deuxième point, il faudra vérifier la cohérence des informations
portées sur la ligne « Received: » comme en II. En gardant présent à l'esprit
qu'elles sont peu sûres (il est délicat d'aller dénoncer des possibles
innocents).

  Sur le premier point, il faut faire un telnet sur le port smtp (25) de
la machine émettrice et initier un dialogue SMTP à la main. Dans la pratique
(pas d'exemple réel sous la main), cela donne quelque chose comme :
$ telnet la.machine.relai 25
<invite>
HELO le-pic.org
<réponse, genre « pleased to meet you » >
MAIL FROM: thirion@mipnet.fr<réponse, genre « sender ok »>
RCPT TO: thirion@mipnet.fr
  Là, si ça répond quelque chose du genre « recipient ok », cela signifie
que la machine va relayer pour un tiers (moi ; du moins s'il ne s'agit
pas d'une machine acceptant légitimement les courriers pour mipnet.fr).

  La bonne réponse (pas de relai) est quelque chose du genre « relaying
denied ».

  Dans le cas où le relai est encore ouvert, il faut écrire à l'administrateur
de la machine pour lui demander de corriger la situation. En cas de réponse
non satisfaisante (ou de non réponse), on peut faire l'escalade comme en II.

V. Du bon sens.

  Il faut un peu de bon sens, en plus de la technique.

  Il y a une gradation dans la manière d'envisager le problème. Entre le
mec à qui on a fait croire que le mailing électronique était un nouveau
moyen légitime de se faire connaître et qui l'utilise en toute bonne foi
(comme cela semble être le cas de Mr Alan LEE (dont le message « "OEM"
Tools and Products » a servi de prétexte à la discussion autour de
la querelle (qui aurait du rester) privée entre Éric et Arnaud) et
quelqu'un qui ne met d'autre coordonnées que téléphoniques dans son
message et utilise un From: falsifié (ou, pire, un relai), la réaction
ne devrait pas être la même.

  Pour Mr LEE, un courrier poli expliquant que ce qu'il a fait n'est pas
bien devrait suffire (il est vraisemblable qu'il en a déjà reçu plus qu'il
ne le souhaite !).

  Pour les autres, comme ils ne sont pas identifiables personnellement, et
que leur manoeuvre de maquillage montre qu'ils sont conscients de ce qu'ils
font, il faut réclamer la fermeture du compte du coupable.

-- 
Marc Thirion              | Toulouse, France
Un Travail pour Chacun    : http://www.multimania.com/untravailchacun/
Marc.Thirion@ISOscope.com : http://www.ISOscope.com/Pérennité des logiciels et des systèmes





---------------------------------------------------------------------
Aide sur la liste: <URL:mailto:linux-31-help@savage.iut-blagnac.fr>Le CULTe sur le web: <URL:http://www.CULTe.org>