Il y a 2 façons d’implémenter cette procédure de désabonnement : soit en précisant une URL pour la désinscription, soit en précisant une adresse email.

Voici quelques exemples d’implémentation :

List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: <mailto:list-manager@host.com?body=unsubscribe%20list>
List-Unsubscribe: <mailto:list-off@host.com>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,<mailto:list-request@host.com?subject=unsubscribe>

L’année dernière, Microsoft a implémenté cette fonctionnalité dans son webmail pour les adresses hotmail, msn et live et intègre le lien de désinscription dans son interface à partir du moment ou l’utilisateur demande l’affichage des images.

Cet été, c’est au tour de Gmail d’intégrer cette fonctionnalité dans son interface de messagerie.

Selon diverses études, les internautes utilisent le bouton de report pour spam pour se désabonner des emails qu’ils reçoivent, les formulaires de désabonnement classique n’inspirent plus confiance aux internautes.

D’autre part, les reports pour spam via le bouton prévu a cet effet sont aujourd’hui le principal facteur de la délivrabilité chez les principaux webmail (gmail, hotmail, yahoo, aol) en influant sur la réputation de l’expéditeur.

Il est donc important d’utiliser cette fonctionnalité afin de minimiser les reports pour spam qui aurait pour but une désinscription.

Un spammeur envoie un email en utilisant en expéditeur un domaine qu’il souhaite attaquer, ce qui est un cas très classique.
Le spammeur envoie une campagne de 15 millions d’emails via des PC zombie. Que va-t-il se passer si le serveur de mail qui reçoit le spam renvoit un bounce à l’expéditeur ?

Un serveur de mail bien configuré répondra :

HELO forged.domain.name
MAIL FROM: victim@victimdomain.tld
RCPT TO: NoSuchUser@yourcompany.tld
550 User unknown

Dans ce cas là, votre serveur de mail est inoffensif.

Mais si votre serveur de mail n’est pas bien configuré, accepte le message et qu’un peu plus tard il renvoie un message de bounce à l’expéditeur, il s’agit d’une utilisation abusive du serveur de mail de la victime dans la mesure où celui ci n’a rien envoyé à votre serveur.

Et que ce passerait il si des millions de serveur faisait la même chose ?
Le serveur victime pourrait être rapidement surchargé et serait susceptible de tomber avec tout les désagréments qui s’en suivent…

On notera que les listages chez BackScatterer.org sont de 30 jours et qu’un délistage anticipé après résolution du problème peut être envisagé moyennant un don paypal de 50€ !

Le site de Backscatterer :
http://www.backscatterer.org/

Tester l’ip de votre serveur de mail :
http://www.backscatterer.org/?target=test

Ce protocole étant vieux et simple, il comporte des failles permettant d’usurper l’identité de l’expéditeur.
Dans la dure lutte contre diverses fraudes par email, il a été important de mettre en place un moyen d’identifier les véritables expéditeurs de messages.

Le but de l’authentification est de permettre aux expéditeurs de prouver qu’ils sont bien ceux qu’ils prétendent et d’éviter de voir leur identité usurpée.

Seulement, comme souvent en informatique, quand il a fallu définir une norme, les géants de ce monde ont immédiatement tiré la couverture à eux en définissant leur propre vision de l’authentification. On se retrouve aujourd’hui avec 4 normes majeures à respecter :

- Sender Policy FrameWork (SPF) :
Utilisé par Google et AOL. Dans ce cas, une ligne de code est ajoutée dans l’entête du message (header smtp) qui indique au serveur qui reçoit le message qu’il peut interroger le serveur DNS de l’expéditeur de façon à savoir si l’IP émettrice est bien autorisée à expédier des messages à partir de ce domaine.

- SenderID Microsoft :
Utilisé par Hotmail et certainement par le nouveau système de Microsoft, WindowsLive Mail.
Le principe de fonctionnement est similaire au SPF, c’est une interrogation du serveur DNS de l’expéditeur qui authentifie le message.
Microsoft ayant déposé le brevet de l’utilisation intellectuelle de ce système, le problème de la généralisation de l’utilisation de cette norme est très politique.

- DomainKeys Yahoo! :
Utilisé par Yahoo! et Google.
Pour la petite histoire, cette norme d’authentification définie par Mark Delany de Yahoo! a été implémentée par Google quelques mois avant Yahoo!.
Le principe de fonctionnement est un peu différent du SPF ou du SenderID, il faut ajouter à l’entête du message, un champ « DomainKey-Signature » qui contient une signature électronique cryptée. Le serveur de mail qui reçoit le message peut alors interroger de serveur DNS de l’expéditeur pour obtenir une clé qui lui permettra de d’authentifier, ou non, le message et son expéditeur.
L’implémentation de cette norme est couteuse en ressource machines.
Attention, un DomainKey mal paramétré peut avoir des effets bien pire que envoi sans DomainKey en terme de déliverabilité !

- DKIM :
Utilisé par AOL, Google et Yahoo!
Très similaire dans son fonctionnement au DomainKey, DKIM est la dernière norme d’authentification en date (mail 2007). Elle est définie par l’Internet Engineering Task Force dans la RFC4871, il s’agit de la fusion du DomainKey de Yahoo! et du IIM de Cisco.

Signer les messages électroniques par ces différentes méthodes est une bonne chose qui garantit à vos messages de ne pas être assimilés à du fishing. Mais cela ne garantit pas aux FAI et ISP que le contenu du message soit de confiance et n’assure pas non plus une bonne réputation.