RFC 3098 : avant la case à cocher du consentement

Résumé

RFC 3098 voyait la publicité non sollicitée comme un transfert de coûts sur un réseau partagé. Sa réponse était une liste tenue par l'annonceur, composée de destinataires volontaires, avec la non-inscription comme état initial.
La confirmation immédiate devait rappeler l'adresse, la voie de soumission, l'heure, l'hôte source, les en-têtes, l'identité de l'annonceur et le retrait. Elle rendait la demande contestable, pas automatiquement authentique.

L'envoi bon marché déplaçait la facture

Le courrier électronique réduisait presque à zéro le coût marginal d'une adresse supplémentaire. Le destinataire et son fournisseur payaient pourtant la connexion, le stockage, l'administration, le filtrage et le temps d'attention. RFC 2635 décrivait cette inversion : contrairement au courrier papier, la communication électronique de masse faisait supporter une grande partie du coût à ceux qui n'avaient rien commandé.

Publié en avril 2001, RFC 3098 partait de cette économie. Dire qu'Internet n'était pas une ressource gratuite ne relevait pas seulement de la morale. Un message utilisait des systèmes privés, traversait des infrastructures entretenues et occupait l'espace du destinataire. La facilité technique ne supprimait pas les propriétaires ni les coûts.

Le texte n'interdisait pas le commerce en ligne. Il cherchait une frontière où l'annonceur pouvait solliciter une attention sans obliger des inconnus à financer sa prospection. Il devait rechercher les lieux appropriés, afficher une identité réelle, respecter la permission des systèmes et répondre de la liste choisie.

Acheter des adresses n'achetait pas leur légitimité

RFC 3098 s'attardait sur les listes compilées. Elles pouvaient mêler adresses aspirées dans des archives, combinaisons devinées, données périmées et personnes ayant changé d'emploi ou de fournisseur. Le document avertissait même que certains vendeurs transformaient des demandes de retrait en nouveaux fichiers commerciaux.

Le principe dépassait la prudence d'achat. Acquérir un fichier ne transférait pas la responsabilité. Le ciblage, l'affichage de l'identité, l'autorisation d'utiliser les systèmes et l'entretien de la liste restaient à la charge de l'annonceur qui espérait en tirer un bénéfice.

Une liste constituée volontairement ne devait pas davantage être revendue. Une permission accordée à une entreprise ne devenait pas silencieusement une permission pour ses partenaires. La liste matérialisait une relation limitée avec un expéditeur nommé, non un actif librement transmissible.

Le réglage initial désignait celui qui devait agir

La case proposée par RFC 3098 appartenait à une architecture plus large. La personne devait savoir que des données étaient recueillies. Si elles servaient à des envois, cette intention devait être annoncée clairement. Elle devait pouvoir fournir l'information demandée sans accepter de publicité.

Le RFC recommandait que l'absence d'envoi soit le choix par défaut. Entrer dans la liste exigeait un acte volontaire, par exemple cocher une demande de messages commerciaux. L'inertie protégeait donc la non-inscription.

Ce détail d'interface rendait à l'annonceur le coût de l'acquisition. Il lui fallait obtenir une décision positive au lieu de profiter d'une case précochée ou d'une finalité dissimulée dans un formulaire sans rapport. La liste pouvait être plus petite, mais chaque adresse possédait une relation plus nette avec une demande exprimée.

Une case ne prouvait cependant ni compréhension, ni identité humaine, ni conformité juridique universelle. RFC 3098 signalait la diversité des juridictions et plaçait sur l'annonceur la vérification du droit applicable. Sa contribution historique réside dans le défaut et le contrôle, pas dans la forme graphique de la case.

La confirmation rendait l'inscription vérifiable

Un formulaire public permet à un tiers de saisir l'adresse d'autrui. RFC 3098 distinguait donc les traces d'une demande de l'authenticité de l'acte. Seul le propriétaire de l'adresse pouvait attester la souscription, et toute soumission devait recevoir une confirmation immédiate.

Cette confirmation ne devait pas être un simple message de bienvenue. Elle indiquait l'adresse inscrite, le mode de soumission, la date et l'heure, l'adresse IP de l'hôte source, les en-têtes complets lorsque disponibles, l'identité et les contacts de l'annonceur, ainsi que le moyen de se retirer définitivement.

L'ensemble formait une provenance élémentaire. Un destinataire inscrit à son insu pouvait voir l'événement et le contester. Un litige disposait d'une heure, d'une route et d'un contexte plutôt que d'une ligne opaque dans une base commerciale.

Ces éléments ne créaient pas une certitude absolue. Une adresse IP n'identifie pas une personne. La livraison d'une confirmation ne prouve pas que le titulaire a soumis le formulaire. Les en-têtes aident une enquête sans devenir une autorisation. Le dispositif offrait une notification et une voie de contestation.

Le retrait fermait la boucle

Une préférence peut changer. RFC 3098 demandait d'expliquer le retrait et de garder privées les données de la liste. La relation commencée par un choix devait conserver une sortie accessible.

D'autres RFC couvraient des surfaces voisines. RFC 2369 normalisait List-Unsubscribe et d'autres commandes d'abonnement. RFC 2142 documentait des boîtes opérationnelles telles qu'ABUSE et POSTMASTER. RFC 2505 et RFC 3013 traitaient du relais non autorisé et de la responsabilité des opérateurs. Pratique de l'expéditeur, contrôle du destinataire et défense de l'infrastructure étaient trois autorités distinctes.

La présence d'un en-tête ne prouvait pas qu'une demande était exécutée. Une boîte d'abus pouvait rester muette et un lien échouer. Il fallait observer la séquence entière : demande, notification, réaction, arrêt des futurs envois et traitement ultérieur de l'adresse.

Conseil, exploitation et droit ne se confondaient pas

RFC 3098 était un document Informational, également FYI 38. Il n'était ni Standards Track, ni loi, ni certification. Il ne mesurait pas l'adoption de ses recommandations. Il décrivait les contrôles qu'un annonceur responsable devait exercer sans prouver qu'ils furent mis en œuvre.

La loi américaine CAN-SPAM date de 2003. La FTC décrit notamment des obligations d'identification et de retrait. Cette autorité juridique ultérieure ne doit pas être projetée sur RFC 3098 comme si le RFC l'avait promulguée ou inspirée sans preuve législative. Le conseil communautaire et l'obligation légale suivent des chaînes différentes.

L'apport durable de RFC 3098 est opérationnel. Il rend visibles des décisions souvent cachées : qui choisit le réglage initial, détient la liste, conserve la trace, affiche son identité et honore le départ. Sa réponse place continuellement contrôle et coût auprès de l'acteur qui recherche le bénéfice commercial.

Cette modestie fait sa valeur historique. Le modèle ne garantit ni consentement, ni honnêteté, ni conformité. Il rend une prétention de permission inspectable et donne au destinataire un moyen de la contester. Avant que le consentement ne devienne un mot d'interface omniprésent, RFC 3098 avait compris que la case, la confirmation et la propriété de la liste distribuaient le pouvoir sur un réseau partagé.

Avant que le consentement ne devienne une case à cocher : RFC 3098

Pourquoi c'est important

Résumé

L'envoi bon marché déplaçait la facture

Acheter des adresses n'achetait pas leur légitimité

Le réglage initial désignait celui qui devait agir

La confirmation rendait l'inscription vérifiable

Le retrait fermait la boucle

Conseil, exploitation et droit ne se confondaient pas

Sources

Contexte approfondi du profil

Strategic Circle

Leadership Alliance

Briefing du Strategic Circle

Briefing Leadership Alliance