SEPAmail : utilisation des protocoles de l'internet SMTP, SMIME, HTTP, REST, SOAP, IP, DNS...

Le protocole SEPAmail peut se définir comme un ensemble de règles permettant de mettre en oeuvre une messagerie entre un expéditeur et un destinataire (appelés les utilisateurs de SEPAmail) via des relais (appelés adhérents du réseau privé SEPAmail).

Ces relais  sont des fournisseurs d'accès au réseau SEPAmail pour le compte de leurs clients.
Le rôle de ces relais est :

• de relayer les messages de leur client sur le réseau SEPAmail
• d'authentifier leurs clients quand ils émettent ou reçoivent un message SEPAmail
• d'accuser réception des messages au nom de leur client destinataire

Pour réaliser ces fonctions en se servant d'un réseau de transport public comme internet, le protocole SEPAmail met en œuvre trois couches d'abstraction :

• une enveloppe SEPAmail, qui, dans l'état de l'art du moment, est une enveloppe SMTP/S-MIME
• une missive SEPAmail qui, pour le moment, est un flux xml contenant un entête et un corps
• un message SEPAmail qui, pour le moment, est un flux xml dérivé d'un gabarit de message générique à entête et corps.

Cette double encapsulation au sein d'une messagerie à relais permet de sécuriser la messagerie et de faire transiter des messages sur le réseau public internet d'un expéditeur à un destinataire avec un bon niveau de confiance, de confidentialité, d'intégrité.

Il existe deux façons de faire transiter les enveloppes SEPAmail:

• le mode canonique qui est pour le moment un échange SMTP dans l'état de l'art
• le mode flash, voulu par les premiers adhérents qui est, pour le moment, un échange web-services de serveur à serveur à l'aide du protocole SOAP sur HTTP(S) ou REST sur HTTP(S)

On peut donc schématiser l'utilisation des couches protocolaires par le schéma suivant:

Les couches utilisées par le protocole SEPAmail

Nous retrouvons dans la colonne de gauche les couches du modèle TCP/IP, puis les couches du protocole SEPAmail et enfin les protocoles standards utilisés:

• S-MIME au sein de SMTP pour la couche enveloppe
• un échange SMTP pour l'échange SEPAMail en mode canonique (le plus naturel et le moins couteux)
• un échange SOAP sur HTTP pour l'échange SEPAmail en mode flash tel qu'implémenté pour l'expérimentation (le plus couteux et pas très naturel sauf à implémenter SEPAmail au sein d'une prise SOAP plus générale)
• un échange REST sur HTTP pour l'échange SEPAmail en mode flash et sobre (rapide, moins couteux que SOAP, naturel car SEPAmail permet d'échanger une ressource enveloppe SEPAmail)
• TCP comme couche transport quand il est mis en oeuvre sur le réseau à bas coût internet
• IP et DNS pour la couche réseau

A la lecture de ce schéma, nous voyons que SEPAmail est un protocole en couches utilisant des standards du web. SEPAmail écrit que cette utilisation doit être réalisée dans l'état de l'art, ce qui, signifie, par exemple :

• pour la couche HTTP, l'utilisation de la version 1.1 pour les possibilités de négociation de contenu et de connexion persistante,
• pour la couche S-MIME, l'utilisation de sha256 au minimum à la place de sha1 selon les recommandations récentes.

Les règles de l'état de l'art pour les protocoles utilisés par SEPAmail sont, si besoin, précisées dans des règles opérationnelles issus des travaux des adhérents SEPAmail et partagés entre eux.
Ces règles opérationnelles précisent également les restrictions de l'utilisation de certains protocoles en expliquant dans la mesure du possible les raisons afin qu'une règle ne soit pas appliquée indéfiniment si la raison a disparu.

Le standard SEPAmail n'explique donc, ni l'état de l'art des couches utilisées, ni l'utilisation de ces couches.

Prenons un exemple pour bien comprendre ce que cela peut signifier pour celui qui implémente SEPAmail au sein d'un logiciel.

Supposons que l'adhérent de l'expéditeur d'un message envoie une enveloppe SEPAmail en mode canonique avec un algorithme cryptographique non supporté par le système récepteur de l'adhérent du destinataire, alors, il est normal que ce système récepteur réponde un code de type 476 ou 576 (Cryptographic algorithm not supported) sur la couche SMTP, conformément à la RFC 3463.

Si maintenant cette même enveloppe est conforme du point de vue SMIME avec un algorithme supporté par S-MIME et l'agent smtp (MTA) mais que l'enveloppe SEPAmail utilise un algorithme non permis par le protocole SEPAmail, une bonne façon de répondre est de répondre sur la couche SEPAmail, c'est à dire d'envoyer une missive d'acquittement avec un statut NAK et un code retour 573 (Unsupported algorithm or security function ), conformément au fonctionnement proposé par la SMIRK MIS 1202.


Le principe général est ainsi, comme le veut l'usage avec les protocoles internet, de répondre sur la bonne couche des erreurs de la couche et de ne répondre sur la couche SEPAmail que pour ce qui concerne le protocole SEPAmail.

Il est important de noter que le transport d'une enveloppe SEPAmail doit s'imaginer en premier lieu par le mode canonique, c'est à dire via le protocole d'échange SMTP, puisque c'est le mode naturel de la messagerie SEPAmail.
Le mode flash doit être implémenté de façon cohérente au mode canonique, que ce soit via SOAP ou REST, sujet qui fera peut-être l'objet d'un billet.

Vocabulaire SEPAmail : mode d'échange canonique versus flash

Le standard SEPAmail définit la structuration de l'information échangée, une organisation pour l'adressage, les séquences d'envoi/réception.
Concernant l'échange à proprement parler de l'information, la documentation cite de deux modes : le mode canonique et le mode flash.

Le mode d'échange canonique

L'adjectif canonique doit être compris dans son utilisation usuelle en mathématiques comme en informatique, c'est à dire standard ou encore naturel et instinctif.
SEPAmail est une messagerie sur internet, le mode d'échange canonique est donc celui de la messagerie électronique, c'est à dire le mécanisme d'échange proposé par le protocole SMTP.

Ce protocole met en œuvre le transfert direct de serveur à serveur et le relais si besoin. Il repose sur des protocoles tiers tels que le DNS, IP, TCP, ainsi qu'un mécanisme d'extensions du protocole qui permet notamment l'implémentation de priorité.
Enfin, il définit une liste de commandes pour permettre de dialoguer entre deux serveurs et, si besoin, différer la remise effective du message.
Cette souplesse protocolaire permet d'éviter de perdre des messages si l'un des composants automates de la messagerie n'est pas joignable.

En théorie, un message peut être distribué à son destinataire plusieurs jours après l'émission par son expéditeur. En pratique, la messagerie électronique est souvent très rapide; nous sommes habitués depuis des années à recevoir nos messages électroniques dans un temps très court (souvent plus rapide que les SMS) et c'est même cette particularité qui a fait le succès et la généralisation de la messagerie électronique.

Pour être efficientes dans la mise en œuvre du protocole SMTP, la plupart des applications dédiées à l'échange des messages (applications dites MTA comme Mail Tranfert Agent) ont mis en place un mécanisme efficace de files d'attente et c'est ce mécanisme qui permet une bonne articulation entre des applications différentes avec des contraintes souvent divergentes.

SEPAmail repose nativement sur le protocole SMTP pour la structuration de l'information (enveloppe SEPAmail = enveloppe SMTP).
SEPAmail repose aussi nativement sur le protocole SMTP pour l'échange de cette information.
Ainsi, une enveloppe SEPAmail peut transiter par les systèmes de messagerie électronique sans aucune modification de ces systèmes.
Avec le mode d'échange canonique, SEPAmail est totalement compatible avec la messagerie électronique existante.

Le mode d'échange flash

Le mode d'échange canonique ne garantit pas un temps très court pour l'échange des données.
SEPAmail définit donc, lorsqu'il est important d'échanger rapidement une enveloppe SEPAmail, un mode d'échange flash.

Celui-ci repose sur un mécanisme de services web avec une garantie de réponse courte dite flash, de l'ordre de quelques secondes, comme en monétique.

C'est ce mode d'échange qui est en cours d'expérimentation dans l'esprit  qui peut le plus peut le moins. Cette expérimentation permet de bien s'assurer des délais raisonnables bout à bout que l'on peut garantir selon la charge et l'organisation des systèmes d'information bancaires ainsi que les coûts maximums de l'infrastructure flash.

Quelques réflexions sur le mode d'échange batch

La monétique et les systèmes informatiques bancaires en général sont assez friands de traitements par lots (batch processing) à des temps programmés à l'avance (vacations) et donc non à la demande comme les traitements transactionnels sur requêtes d'un client. Certains acteurs bancaires adhérents de SEPAmail mettent en œuvre de tels traitements au sein de leur système d'information.

Ce mode d'échange n'est pas souhaité entre les adhérents pour plusieurs raisons :

• il va à l'encontre de la logique message unitaire de SEPAmail
• il induit une gestion centralisée et pilotée de la charge alors que SEPAmail privilégie une gestion répartie pair à pair de l'échange.
• il repose sur un mode non transactionnel alors que SEPAmail utilise le réseau IP, transactionnel par nature

Le web service sur internet et l'illusion du temps réel

Le temps réel est à la mode dans le monde internet et le service web semble être l'objet de toutes les attentions actuelles pour mettre en œuvre du temps réel.

Cependant, derrière ce terme se cache des contradictions qui sont rarement mises en avant.

Un système temps réel est généralement défini par sa capacité à délivrer un résultat dans un temps fini et garanti, ce qui oblige toute la chaîne des procédés utilisés à être en temps réel.

Or, le réseau IP repose aujourd'hui :

• sur des machines dont les système d'exploitation ne sont pas des systèmes temps réel
• sur des protocoles qui ne peuvent garantir le résultat et encore moins en temps fini

Le réseau IP repose sur le paradigme du best of qui est peu compatible avec le temps réel.

On devrait donc parler de temps court au lieu de temps réel. On peut parler aussi de temps synchrone entre deux automates, dans la transaction entre le serveur et le client.

Le mode flash SEPAmail est un mode synchrone alors que le mode canonique est un mode asynchrone.

Le service web (web services) peut être vu comme une généralisation du service de page web à l'internaute.
Les protocole de la famille tcp/ip (dont http) ont permis dans un premier temps à des automates de servir de l'information sous forme de pages html à des êtres humains organisés.

Très vite, des automates programmables doués d'ubiquité se sont substitués aux internautes pour transformer, traiter l'information et la restituer autrement (opérés de façon exceptionnelles par exemple par google, yahoo, kelkoo). Les services webs sont apparus pour permettre la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués.

Les services webs présentent des particularités souvent oubliées et qu'il convient de bien appréhender dans le cadre de SEPAmail. Ils sont généralement en mode client/serveur avec une structure de coût essentiellement déportée sur le serveur. Ils sont plutôt gros consommateurs de ressources par rapport à d'autres implémentations. Ils sont souvent concurrentiels sur le réseau IP des transactions hommes/machines et l'articulation avec les échanges homme/machine est rarement facile à mettre en place.

L'engouement pour les architecture reposant sur des appels de procédures à distances (RPC ou Remote Procedure Call) a permis de régler quelques problématiques liés au secret de fabrication, au coûts d'intégration ou encore aux contraintes de distribution des services.

C'est dans ce contexte que SEPAmail a conçu un mode flash de cette messagerie sécurisée qui, devrait, à terme, n'être utilisé que pour les messages à forte valeur ajoutée pour les clients finaux.