Flux RSS - La vie du site - Nouveautés et mises à jour
Assiste.com - Sécurité informatique - Vie privée sur le Web - Neutralité d'Internet Assiste.com - Sécurité informatique - Vie privée sur le Web - Neutralité d'Internet

abuse : adresse rôle abuse@domain

abuse, abuse@domaine.tld - adresse rôle (adresse courriel standard « de facto ») réservée à un usage spécifique. Elle dirige les courriels vers l'hébergeur du domaine.

abuse : adresse rôle abuse@domain (adresse « rôle »)

Vous êtes victime d'une attaque en provenance d'un site ou vous pensez qu'un site a une activité ou un contenu inapproprié ou est à l'origine d'attaques ou de déploiements de malveillances ou est hacké et sert à lancer des attaques, etc. : écrivez à abuse@nom du site.tld (ou, parfois, à abus@nom du site.tld ou spam@nom du site.tld).

L'adresse email « abuse » existe sur tous les domaines, pour tous les protocoles, et est implicite. Elle a un statut particulier. Elle est, par convention tacite, réservée et sert à exprimer à l'hébergeur d'un domaine (ou à un FAI ou un régistrar) un usage inapproprié ou abusif ou dangereux d'un domaine créant un risque sécuritaire ou d'usage de l'Internet mettant en péril les usagers de l'Internet et engageant la responsabilité des FAI (Fournisseur d'Accès Internet) ou des hébergeurs ou des régistrars (que vous payez pour qu'ils vous permettent d'utiliser le Web, sur l'Internet, de manière sûre et paisible).

Elle est de la forme :

  • « abuse » @ « nom du domaine » . « TLD »
  • « abuse » @ « nom de l'hébergeur domaine » . « TLD »
  • « abuse » @ « nom du FAI » . « TLD »
  • « abuse » @ « nom du registrar » . « TLD »

Chercher l'adresse abuse d'un domaine : https://www.abuse.net/lookup.phtml

Le titulaire recevant la plainte (qui doit être motivée et prouvée avec l'envoi du code source complet d'un email ou du code source complet d'une page Web) :

  1. Analysera le code source pour déterminer le type d'abus et vérifiera la réalité de ce qui est dénoncé (risques de dénonciations calomnieuses). Il prendra alors une mesure à l'encontre du site fautif.
    1. Il signalera l'abus au registrant avec menace de suspendre le service dès qu'une autre plainte se présentera
    2. Si l'analyse révèle que l'abus est de type phishing, fraude 419 ou déploiement de malwares, la suspension du site sera immédiate. Il appartient au webmaster du site, même hacké, de sécuriser/restaurer son site.

Exemples (il existe environ 2 milliards de sites Web au monde (mars 2019) pour des dizaines de milliers d'hébergeurs, de registrars et de FAI) :

  • 1&1 IONOS
    abuse@ionos.com
    abuse@1and1.com
  • Alice
    abuse@aliceadsl.fr
  • AOL
    aol_phish@abuse.aol.com
    abuse@aol.com
  • Arcor
    abuse@arcor.de
  • Bouygues
    abuse@bbox.fr
  • Dartybox
    abuse@dartybox.com
  • EDPNET
    abuse@edpnet.net
  • ex2
    abuse@ex2.com
  • Facebook
    phish@spamreport.facebook.com
  • FranceGenWeb
    abuse@francegenweb.org
  • Free
    abuse@free.fr
  • Gmail
    gmail-abuse@google.com
  • GoDaddy
    abuse@godaddy.com
  • Google
    abuse@google.com
  • Hetzner Online AG
    abuse@hetzner.de
  • Hostkey
    abuse@hostkey.com
  • IANA Internet Assigned Numbers Authority
    abuse@iana.org
  • ikoula
    abuse@ikoula.com
    ikoula@ikoula.com
  • Infium
    abusemail@infiumhost.com
  • infomaniak
    abuse@infomaniak.ch
  • iweb
    abuse@iweb.com
  • iWeb
    abuse@iweb.com
    abuse@noc.privatedns.com
  • Kabel Deutschland
    abuse@kabeldeutschland.de
  • La Poste
    abuse@laposte.net
  • Lasotel
    abuse@lasotel.com
  • name
    support@name.com
  • Namebay
    abuse@namebay.com
  • Network Information Center
    tld-abuse@nic.ru
  • Numericable
    abuse@numericable.fr
  • nuxit
    abuse@nuxit.com
    abuse@netissime.com
  • Onatel
    abuse@onatel.bf
  • One
    abuse@one.com
  • Online
    abuse@iliad-entreprises.fr
    abuse@online.net
    abuse@proxad.net
  • Orange
    abuse@orange.fr
    abuse@orange-business.com
  • OVH
    abuse@ovh.com
  • Paypal
    spoof@paypal.com
  • Planethoster
    abuse@planethoster.net
  • Reliance
    antiabuse.support@relianceada.com
    abuse@relianceada.com
    abuse.support@relianceada.com
  • SFR
    abuse@neuf.fr
    abuse@gaoland.net
    emailsuspect@sc.sfr.fr
  • TekSavvy
    abuse@teksavvy.com
  • Telecom Italia
    abuse@retail.telecomitalia.it
  • Twitter
    net-abuse@twitter.com
  • Ubiquity Server
    abuse@us.leaseweb.com
    abuse@nobistech.net
  • UptoBox
    uptobox.abuse@gmail.com
  • Wanadoo
    abuse@wanadoo.fr
  • Yahoo UK
    uk-abuse@cc.yahoo-inc.com
  • Yahoo!
    phishing-abuse@cc.yahoo-inc.com
    abuse@yahoo-inc.com


Si un site est hacké par un pirate qui s'en sert pour lancer des attaques (DDoS ou Phishing, etc.), et que ce site se trouve sur un serveur mutualisé (partagé avec des milliers d'autres sites), le serveur dans sa totalité va rapidement être introduit dans de nombreuses listes noires (blacklist) et c'est la totalité des domaines hébergés sur ce serveur qui vont être bloqués sous le même motif, ce qui est dramatique et laisse des traces d'e-réputation ternissant l'image de chacun de ces domaines sur le long terme.

  • Tous les webmasters de ces milliers de sites bloqués doivent pouvoir demander des explications à leur hébergeur à l'adresse abuse@hébergeur et se plaindre
  • Toutes les victimes d'un site doivent pouvoir signaler à l'hébergeur de ce site le problème à l'adresse abuse@hébergeur

On trouve l'hébergeur d'un domaine avec des outils de type WHOIS ou avec des outils de type Trouver les serveurs email (MX) d'un domaine, mais l'adresse abuse@domaine.tld envoie automatiquement à abuse@hébergeur.tld ou abuse@registrar.tld.

Dans quels cas il ne faut pas utiliser l'adresse abuse@, mais porter plainte (et où porter plainte)

Les cas de contenus touchant à la pédophilie, au terrorisme, à la fabrication d'armes et explosifs, à l'appel ou la propagation de la haine raciale ou religieuse, à l'endoctrinement sectaire, etc. ne doivent pas être signalés à une adresse « abuse », ce qui pourrait mettre la puce à l'oreille d'un webmaster cybercriminel qui s'empresserait de camoufler ses documents : il faut s'adresser immédiatement à un officier de police judiciaire de son commissariat de police ou à des adresses de contact pour signaler - dénoncer - porter plainte. Typiquement, c'est la Pharos qui collecte ces natures d'informations.

  • Si le domaine (le site) en question est lui-même victime d'une usurpation et que les malveillances ou abus se propagent au travers de son domaine, à son corps défendant (le domaine est hacké, etc.), le webmaster fera ce qu'il peut pour y mettre un terme (correction de failles de sécurité, effacement complet du site (de tout l'hébergement) et reconstruction depuis zéro, etc.).
  • Si le webmaster n'est pas diligent, il est possible de s'adresser à son hébergeur qui pourra suspendre son site pour le forcer à réagir.
  • Si le problème provient de failles dans les technologies installées par l'hébergeur (Apache, PHP, MySQL, etc. ...) qui ne sont pas à jour, le lui signaler immédiatement, car sa réaction devra être immédiate au risque de perdre ses clients. Le webmaster victime de la négligence de son hébergeur, alors qu'il le paye, se retournera contre son hébergeur.

Les « adresses rôle », des normes « de facto »

Divers documents Internet (RFC) ont spécifié des noms de boîte aux lettres à utiliser pour atteindre les opérateurs d’un service ; par exemple, la [RFC 822 §6.3, C.6] exprime la nécessité de la présence d'un nom de boîte aux lettres <POSTMASTER@domain> sur tous les hôtes ayant un serveur SMTP (Simple Mail Transfer Protocol).

D'autres protocoles bien connus ont un standard « de facto » pour leur nom de boîte aux lettres, tels que <USENET@domain> pour NNTP (voir [RFC 977]) et <WEBMASTER@domain> pour HTTP (voir [HTTP]). Il y a, dans les RFC, la spécification d’un nom de boîte aux lettres « devenu standard de facto », choisi par la logique et son « usage naturel répandu », pour chacun des protocoles de communication existants.

Les normes « de facto » (normes, « de fait », d’une manière non juridique, reconnues de facto) existent également pour des noms de boîtes aux lettres bien connus qui n’ont rien à voir avec un protocole particulier, par exemple <ABUSE@domain> ou <TROUBLE@domain>.


Les « adresses rôle »

Certaines adresses courriel sont réservées, par habitude ou convention, à un usage spécifique. Quelques-unes d'entre elles sont même fixées et standardisées dans des RFC. Leurs noms désignent la fonction du destinataire, sur un domaine, sans connaître ce destinataire. Leurs justifications principales sont :

  • Simplifier la vie des administrateurs de serveurs lorsque ces serveurs sont nombreux et différents
  • Pouvoir s'adresser au responsable d'une fonction particulière sur un domaine (un site Web), sans le connaître et sans connaître son adresse courriel. Il s'agit de pouvoir accéder au responsable le plus pertinent d'une fonction, les yeux fermés, sur tous les domaines du monde.

Évidemment, la réalité de l'existence de ces responsables d'une fonction dans un domaine ne concerne que les immenses domaines avec des centaines ou milliers d'employés. L'étudiant qui achète un nom de domaine juste pour publier son CV (Curriculum Vitae) sur son site Web mono-page, est loin de tout cela et il est toutes les fonctions à lui tout seul.

Dans tous les cas, trois fonctions existent obligatoirement et trois adresses courriel sont obligatoires, même chez l'étudiant et son site Web monopage. En achetant un nom de domaine, chez un registrar, le registrant doit créer les 3 adresses courriel « registrant@ », « admin@ » et « tech@ », qui lui sont demandées. Par exemple :

Adresses courriel rôle (réservées) demandées au registrant d'un nom de domaine
Adresses courriel rôle (réservées) demandées par un registrar au registrant lors de l'achat d'un nom de domaine, et que l'on retrouve dans tous les (bons) Whois du monde.


Ensuite, il existe une petite liste de noms de boîtes courriel dites « adresses rôle » qui sont préférentiellement réservées à des destinataires particuliers, désignés par leurs fonctions, dans une organisation. Ce sont les mêmes noms de fonction utilisés dans toutes les langues et ils sont fixés (standardisés) par les RFC.

Ces « adresses rôle » se basent sur le protocole utilisé et permettent de joindre le responsable pertinent d'une fonction. Elles sont recommandées dans des RFC qui ont valeur de standard, dont les RFC 822, RFC 959, RFC 2068, RFC 1033, RFC 1035, RFC 976, RFC 977, RFC 2142 qui évoquent des « Mailbox names for common services, roles and functions » (« Noms de boîtes aux lettres pour des services, rôles et fonctions communs »).

Les adresses courriel suivantes sont donc réservées à des destinataires particuliers, pertinents dans une fonction (dans un domaine) :

Enfin, les autres fonctions ne peuvent être évoquées dans une RFC. Elles relèvent de chaque organisation (ventes, achats, marketing, service après-vente, petites annonces, jobs, etc.). Une liste d'adresses courriel de fonctions (rôles) souvent rencontrées peut être établie (il y en a certainement d'autres).

Pour l'internaute « normal » visitant un site Web, seules les adresses postmaster@, abuse@ et webmaster@ sont « intéressantes » si vous avez quelque chose à faire remarquer.

Ces 3 « adresses courriel fonction « ou « adresses courriel rôle » devraient toujours exister pour tous les domaines (tous les sites Web), même s'il s'agit d'un domaine personnel, microscopique, d'une seule page (sauf si le site donne clairement une ou des adresse(s) de contact, généralement en bas de ses pages ou dans ses clauses et conditions, ou indique un autre moyen de communication comme un forum de discussion).

Adresse courriel de contact indiquée dans le site Web
Adresse courriel de contact indiquée dans le site Web


L'anonymat légalisé est une imbécilité (une véritable criminalité). Dernier en date, le RGPD entré en vigueur le 25 mai 2018). Il y a une complète confusion entre la vie privée et l'anonymat. La protection de la vie privée ne passe absolument pas par l'anonymat. Autant la vie privée doit être totalement privée (ce que je fais sur le Web, à titre personnel, ne vous regarde pas), autant ce qui est « publié » ne doit jamais l'être par une personne physique ou morale qui se cache, ce qui enlèverait tout crédit aux propos, voire les rendrait suspicieux. Se souvenir, par exemple :

Il a existé, de 2001 à 2012, un domaine (« rfc-ignorant.org ») qui maintenait une liste noire (blacklist), par crowdsourcing, des sites ne donnant pas d'adresses courriel « registrant@ », « admin@ » ou « tech@ ». Il existe encore (2019), avec certains outils d'analyse de sites Web, le test et signalement de l'inexistence de ces adresses courriel, inexistence considérée comme un mauvais point dans la réputation du site Web.