Résumé

  • Le bloc hérité de Svea 193.105.138.0/24 affiche la boîte partagée sur le domaine Verizon comme contact d'abus sur plusieurs miroirs indépendants, alors que son propre attribut abuse-c au registre est AR23510-RIPE.
  • La même boîte sur le domaine Verizon est affichée pour des titulaires sans rapport, dont Moore Europe Capital Management, IP-Only Networks AB et Rackspace Ltd. — un contact hérité de l'ère des opérateurs plutôt qu'un canal propre à Svea.
  • La politique RIPE 2017-02 (ripe-705) exige une validation annuelle des boîtes d'abus, mais cette validation est un simple contrôle de délivrabilité technique : elle n'envoie jamais de courriel et ne certifie jamais que quelqu'un lit ce qui arrive.
  • Aucune source publique repérée pour ce dossier ne démontre qu'une boîte d'abus Svea ou Verizon est pourvue, surveillée, ou répond aux signalements.

Les faits du registre d'abord. AS211899 (as-name SVEA) est enregistré auprès de ORG-SBA155-RIPE, Svea Bank AB, numéro d'enregistrement 556158-7634, avec l'attribut abuse-c SEAR1-RIPE et admin-c/tech-c JE4899-RIPE — Jorgen Edstrom, dont la fiche personne porte encore l'adresse de la dissoute Svea Ekonomi AB [http://whois.ipip.net/AS211899]. Le préfixe routé 193.105.138.0 - 193.105.138.255, netname SVEA-EKONOMI-SE, descr « Svea Ekonomi AB », statut ASSIGNED PI, créé le 2010-02-18 et modifié pour la dernière fois le 2021-02-02, est enregistré auprès de ORG-SBSA5-RIPE (Svea Billing Services AB) avec abuse-c AR23510-RIPE, maintenu via SWIPNET-LIR-MNT et parrainé par ORG-TA44-RIPE (Tele2) [http://whois.ipip.net/AS211899/193.105.138.0/24]. Pourtant, la ligne « % Abuse contact » de cet objet pointe vers une boîte sur le domaine d'un tiers, différente du propre attribut abuse-c de l'objet. IPinfo montre indépendamment le même contact pour la plage [https://ipinfo.io/AS211899/193.105.138.0/24].

La portée opérationnelle vient de ce que la même boîte fait ailleurs. La boîte identique sur le domaine Verizon est affichée comme contact d'abus pour 195.95.143.0/24 (Moore Europe Capital Management), qui porte une adresse de notification sur le même domaine [https://whois.ipip.net/AS22775/195.95.143.0/24], pour 193.43.151.0/24 (IP-Only Networks AB, AS12552) [https://whoismind.com/ips/193.43.151.0/24], et pour 193.142.244.0/24 (Rackspace Ltd., AS15395) [https://whoismind.com/ips/193.142.244.0/24]. Une boîte affichée pour une banque suédoise, une société financière britannique, un FAI suédois et un hébergeur britannique dans la même région RIPE n'est pas un canal que l'un d'eux a choisi ; c'est une valeur par défaut de l'ère des opérateurs, héritée de la lignée UUNET/MCI-devenue-Verizon-Business. Le domaine se.verizon.com résout toujours sur ns.emea.verizonbusiness.com et les serveurs hérités auth200/210.ns.uu.net [https://whoisfreaks.com/tools/dns/lookup/se.verizon.com], ce qui explique pourquoi la validation peut passer : le domaine et les serveurs de messagerie sont techniquement configurés.

C'est précisément ce que le régime d'exécution du RIPE vérifie. La politique 2017-02, mise en œuvre dans ripe-705, exige que les attributs de boîte d'abus soient validés au moins une fois par an [https://www.ripe.net/publications/docs/ripe-705/], [https://www.ripe.net/community/policies/proposals/2017-02/] et [https://www.ripe.net/manage-ips-and-asns/resource-management/policy-implementation-status/policy-implementation-archive/2017-02-regular-abuse-c-validation/]. La documentation du RIPE NCC sur le mécanisme de validation décrit des contrôles de syntaxe, de DNS et de configuration des serveurs de messagerie ; elle n'envoie pas de courriel à la boîte et ne certifie pas, et ne peut pas certifier, que les signalements sont lus ou traités [https://labs.ripe.net/author/angela_dallara/how-we-will-be-validating-abuse-c/]. Les documents de l'Abuse Working Group du RIPE87 rendent la même frontière explicite : le registre certifie l'accessibilité, pas la réactivité [https://ripe87.ripe.net/wp-content/uploads/presentations/72-RIPE87-AAWG-final.pdf]. Le champ est également exposé par le RIPEstat abuse-contact finder [https://stat.ripe.net/widget/abuse-contact-finder] ; des recoupements sur un enregistrement whois IPv6 sans rapport [https://bash.ws/whois/2a00:801:212:bf71:c526:ec18:36bd:4775], le miroir AS39651 [http://whois.ipip.net/AS39651], la lignée UUNET [https://en.wikipedia.org/wiki/UUNET] et le rôle de Tele2 dans l'internet suédois [https://www.tele2.com/about/our-history/our-stories/theres-no-question-about-it-tele2-built-internet-in-sweden/] replacent ce contact dans son contexte d'ère opérateur.

Pour un rapporteur ou un conseil qui évalue cette surface, la conséquence pratique est une asymétrie : un validateur peut renvoyer « valide » pour une boîte que personne n'a lue depuis des années. Le contact affiché du bloc est la valeur par défaut héritée d'un tiers ; les attributs abuse-c propres de l'objet (SEAR1-RIPE au niveau de l'AS, AR23510-RIPE au niveau du bloc) n'étaient pas récupérables intégralement dans les miroirs publics consultés [http://whois.ipip.net/AS211899/193.105.138.0/24] et [http://whois.ipip.net/AS211899] ; et la chaîne de maintenance pointe vers le rôle SWIP-RIPE de Tele2, ni vers le domaine Verizon ni vers Svea elle-même. Rien de tout cela ne prouve qu'une boîte est morte. Cela prouve que le registre public ne peut pas distinguer une fonction de traitement des abus qui fonctionne d'un pointeur de registre non surveillé — et que le régime de validation, par conception, ne comble pas cet écart.

La seule responsabilité qui s'est démontrablement déclenchée contre Svea Bank AB est venue d'un canal entièrement extérieur à cette surface : l'action anti-blanchiment de Finansinspektionen annoncée le 17 décembre 2025 avec une amende de 170 millions de couronnes suédoises, documentée dans la couverture antérieure de BTW sur le même sujet [https://btw.media/en/svea-abuse-contact-durability-en] et [https://btw.media/en/svea-eknonomi-abuse-role-en]. Un superviseur financier a agi par son propre canal de défaillance ; la surface de contact d'abus n'a produit aucun résultat publié. Ensemble, ces deux faits posent la question institutionnelle que ce dossier laisse ouverte : quand le registre certifie la délivrabilité et ne démontre jamais la réponse, quel événement observable — une réponse horodatée, un rapport de validation nommant la boîte, un résultat d'exécution publié — distinguerait jamais un contact qui fonctionne d'un contact qui n'existe que dans le registre ?