FAQ n°6

Q6.1 : Renvoi, doit-on changer la date ?

La question peut se poser ainsi : si je renvoie une missive comme cela est possible, est-ce que je change la date ?

Une réponse rapide est : NON, on ne change que l'ordre quand on renvoie une missive, en l'incrémentant de un.

Voici une explication détaillée de cette réponse rapide :

On trouve la règle à appliquer dans la directive d'implémentation de la missive :
""If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged."

Quel est le sens de cette règle ?

Pour le comprendre, il faut une petite explication :

• Le message SEPAmail, c'est le signifiant échangé entre les utilisateurs
• La missive SEPAmail, c'est l'enveloppe de messagerie du réseau privé SEPAmail
• L'enveloppe SEPAmail, c'est l'enveloppe de sécurité en cas de transport (mode flash ou canonique) sur un réseau public.

Le protocole SEPAmail, c'est un protocole qui permet :

• cette double encapsulation,
• une authentification des parties par les relais,
• un accusé de réception par l'adhérent pour le compte de son utilisateur, quelque soit le cas d'usage (l'application, le nombre d'acteurs...)
• une forme de "garantie" pour un utilisateur émetteur que son envoi sera acquittée (renvoi, escalade, acquittement obligatoire 24/24 7/7 par l'adhérent récepteur selon la priorité)

Renvoyer une missive, ce n'est pas obligatoire mais une possibilité, offerte si le système émetteur chez l'adhérent considère que l'acquittement des envois précédent pour la même missive n'est pas arrivé.

Par contre, acquitter une missive, c'est obligatoire.

Quand l'émetteur renvoie une missive, voilà ce qu'il dit à son récepteur de missive : "je vous ai déjà émis une missive pour telle personne à telle heure. Comme mon système n'a pas encore enregistré d'accusé réception et que j'ai besoin de cet accusé de réception, je vous renvoie, comme j'en ai la possibilité, la même missive. Pour vous signifier que c'est un renvoi, j'incrémente de 1 l'ordre de la missive. Merci de m'acquitter, comme vous en êtes obligé en tant qu'adhérent, cette missive et les précédentes, si vous les avez reçues."

Quand on raisonne sur ces sujets, il faut absolument ne pas vouloir connaître le statut précis ou le comportement précis de son interlocuteur; mais appliquer le protocole de son point de vue.

Celui qui spécifie le composant qui envoie et reçoit les missives des parties, doit, bien entendu imaginer tous les cas, dont celui pour lequel la contrepartie essaie de frauder ou pour lequel la contrepartie a un système défaillant. Des systèmes de régulation de ces comportements sont présents dans SEPAmail et dépasse le simple cadre de l'acquittement des missives. Pour mémoire, ce sont l'engagement contractuel des adhérents, le procédé d'escalade, la surveillance du réseau par SEPAmail.eu.

Q6.2 :  Pourquoi y a-t-il Acquittement et Aknowledgement dans les types de missives ?

Les schémas XML autour de SEPAmail sont écrits en anglais, pour pouvoir être lus par tous. Les types de missives étaient écrits en français, ce qui ne posait pas de problème pour Service, Nominal et SMAPI qui sont équivalents en anglais mais ce n'est pas le cas pour Acquittement.

En 2010, le committer a donc accepté ma demande de transformer Acquittement en Aknowledgment, tout en conservant Acquittement à des fins de rétro-comptabilité. Les deux termes sont donc équivalents, comme annoncé dans la directive d'implémentation de la missive.

La règle implicite est donc la suivante :

Tout composant mettant en œuvre le standard SEPAmail DOIT accepter en réception les types Acquittement et Aknowledgment.

Mon conseil est de rajouter :

Tout composant mettant en oeuvre le standard SEPAmail DEVRAIT utiliser en émission le type Aknowledgment.

Q6.3 Où peut-on trouver des exemples de flux ?

Cette question revient souvent; elle est tout à fait licite.

J'ai créé en 2013 un espace communautaire pour partager nos exemples.

Il se trouve sur la plateforme google code et a pour petit nom SMITE : SEPAmail I want TEst !

L'espace pourrait être augmenté de nos exemples.

Le problème de chacun est de savoir si son exemple est bien conforme à:

•  les schémas XML
•  les directives d'implémentation
•  les règles opérationnelles entre les adhérents

Pour le premier point, c'est facile puisque tous les outils existent et les schémas sont publiés et stables.

Pour le deuxième point, les directives d'implémentation sont publiées mais certaines règles semblent être encore porteuses d’ambiguïté. La démarche est donc de demander au comitter SEPAmail via l'espace communautaire son avis, soit en direct, soit par la fonctionnalité discuter du wiki.

Pour le troisième point, c'est plus compliqué car ces règles ne sont pas publiées. Pour les avoir consultées, je peux vous assurer qu'il n'y a peu de règles qui touchent aux flux messages ou missive dedans (la taille maximale des flux acceptée pour le moment) mais plus des règles pour connecter entre elles les infrastructures et piloter la mise en production après expérimentation.

Je propose à tous ceux qui souhaitent partager leurs exemples de les aider dans leur démarche. N'hésitez pas à me contacter.

Ces pages sont également ouvertes pour ceux qui désirent partager un billet sur ces sujets.

Je souhaite que nous ne faisions pas comme d'autres communautés à écrire les règles sans partager des exemples qui facilitent leur compréhension.

Q6.4 SEPAmail et RUBIS, c'est la même chose ?

SEPAmail est une messagerie sécurisée fournie par des adhérents SEPAmail à leurs clients ou leurs agents, ceux que l'on appelle des utilisateurs SEPAmail.

RUBIS, comme GEMME, JADE, DIAMOND, sont des applications de SEPAmail qui répondent à un besoin précis des utilisateurs.

Donc, SEPAmail et RUBIS ne sont pas la même chose. Les utilisateurs ne devraient pas entendre parler de RUBIS puisque les cinq adhérents actuels se sont entendus sur la notion de "règlement (via) SEPAmail" pour parler de RUBIS. RUBIS reste un nom de code interne à la communauté SEPAmail.

Q6.5 Quelle est la limite en taille d'un message, d'une missive, d'une enveloppe ?

C'est l'une des exceptions à ce que j'ai dit plus haut. La limite a été fixée dans les règles opérationnelles et elle est de 200kos pour l'enveloppe SEPAmail, c'est à dire trop peu. En effet, comme un fichier pdf (par exemple une facture) est encapsulé dans un message SEPAmail, puis une missive SEPAmail et enfin une enveloppe SEPAmail.

Q6.6 SEPAmail, c'est une norme, un standard, un protocole ?

SEPAmail est un protocole, puisqu'il précise un ensemble de règles pour des acteurs qui cherchent à organiser entre eux une fonctionnalité.

Les français distinguent la norme du standard : la norme est un texte normalisé par un organisme de normalisation reconnue (ou officiel). Le standard est un texte utilisé par une communauté.

Si on reconnait SEPAmail.eu comme un organisme de normalisation officiel, alors SEPAmail est une norme. Ce n'est à mon avis pas encore le cas.

Il existe aujourd'hui une communauté de fait autour de SEPAmail, c'est donc bien un standard de fait.

Q6.7 Quel est le statut de votre blog et de vos réponses ? Puis-je m'y fier ?

Notre blog (nous sommes pour le moment deux rédacteurs) se veut un point de rassemblement de ceux qui participent à la communauté SEPAmail (les lecteurs) et de ceux qui veulent partager des points de vues et des informations sur SEPAmail (les rédacteurs, les interviewés...).

Le blog n'est pas le blog officiel de SEPAmail.eu.

Les éclairages amenés n'engagent donc pas SEPAmail.eu et n'engagent, d'une manière générale, que leur auteur.

Il n'y a pas de comité de validation des billets rédigés.

Comme le blog est lu et (de temps en temps) commenté, vous pouvez, à mon sens, vous fier à ce qui est écrit et vous forger une opinion sur son contenu.

Les deux auteurs sont :

• Olivier Jousselin, comitter du standard de 2009 à 2013, rédacteur de la SMIRK Jade en 2013
• Manfred Olm, co-auteur du premier draft en 2008, de quelques SMIRKs en 2011 et 2012, missionné de 2010 à 2012 pour réaliser le contrôle de cohérence entre le standard et les expérimentations ayant été réalisées.

Nous partageons ainsi avec vous le plaisir que vous avez, nous l'espérons.

FAQ n°5

Q5.1 : RUBIS : Combien de décimales sont autorisées dans le montant à payer ?

Le montant se trouve, dans la requête RUBIS (message ActivationRequest), dans le fragment xml Amt (xpath /sem:ActivationRequest/sem:ReqCompl/sem:Request/pain013:PmtInf/pain013:CdtTrfTx/pain013:Amt/pain013:InstdAmt).
Selon le shema XML du pain013, le montant est un nombre décimal positif qui peut avoir 5 décimales au plus.
Selon la directive d'implémentation RUBIS du message ActivationRequest, le montant ne peut pas être nul.
Le montant minimum est donc 0.00001 et un message avec ce montant valide bien le schéma XML du message.

Ce nombre de décimales permet d'effectuer la conversion entres les différentes devises sans ambigüité sur la deuxième décimale. C'est la règle générale qui a été adoptée en Europe au moment du passage des monnaies nationales à l'euro. Elle parait donc adaptée à l'univers SEPAmail et à la zone SEPA en particulier.

L'EPC a précisé pour le pacs.008 puis le pain.001 une règle plus contraignante qui peut se résumer à "Format rule: The fractional part has a maximum of two digits". On retrouve cette règle par exemple pour l'échange de pain.001 entre une banque et son client (référence IG SCT Bank-Client v7.0, Instructed Amount AT-04).

Certains guides du CFONB reprennent la règle ISO (5 décimales) ou la règle EPC (2 décimales).

La question est donc bien licite pour RUBIS.

Concernant une demande de règlement, quel est le sens de payer un montant avec 5 décimales ?
Dans la plupart des usages proposés par RUBIS, cela n'a aucun sens, donc une règle d'au plus 2 décimales aurait du sens.
D'un autre côté, Rubis ne propose que la demande de règlement et non le règlement lui-même, qui est articulé par la banque de débiteur selon le contrat qu'elle a avec le débiteur. Les cas d'usage qui ont été relevés lors du passage à l'euro, peuvent toujours donc se dérouler avec RUBIS.

Il parait raisonnable donc, pour pouvoir s'articuler avec un règlement par virement et être compatible avec les règles EPC d'implémenter à minima les règles suivantes :

• un créancier DEVRAIT utiliser des montants avec au plus deux décimales s'il n'a pas besoin de conversion
• l'adhérent du débiteur DOIT arrondir à deux décimales selon les règles d'usage des arrondis dans le monde bancaire tout montant émanant d'une demande de règlement avec plus de deux décimales avant d'initier un règlement par virement (pacs.008 ou pain.001)

Q5.2 : Comment doit réagir un adhérent si une missive n'est pas adressée à un de ces clients ou l'émetteur n'est pas chez l'adhérent qui envoie la missive ?

Le cas est simple et se présente de temps à autre.
L'adhérent émetteur de la missive envoie à un adhérent une enveloppe SEPAmail correcte contenant une missive dont :

• l'expéditeur (balise Snd) n'est pas un QXBAN de l'émetteur (mauvais BIC)
• le destinataire (balise Rcv) n'est pas un QXBAN du récepteur (mauvais BIC)

La missive peut donc être acquittée puisqu'elle est valide et lue correctement.

En version 1206, le relai entre les adhérents n'est pas autorisé.

• Conséquence 1 : l'adhérent qui reçoit la missive NE DOIT PAS  la relayer.
• Conséquence 2 : L'adhérent qui a envoyé la missive NE DEVAIT PAS la relayer également.

L'acquittement est donc négatif (NAK).
Le code retour peut être utilisé; c'est 511 pour le premier cas (mauvais Snd) et 512 pour le second (mauvais Rcv)

Q5.3 : peut-on envoyer une missive d'ordre 0 ?

Le schéma XML de la missive (voir ici) décrit une balise MsvOrd comme un entier.
Par contre, la directive d'implémentation de la missive donne explicitement l'usage de cette balise : "Usage Rule : this field must be set to 1 (one) at first sending of a given missive. If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged.
Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges."

On commence à un et on incrémente de un à chaque renvoi.
On acquite une missive avec le même ordre que la missive nominale acquittée.

Que faire alors si on reçoit une missive nominale d'ordre 0 ?
On acquitte négativement (NAK) avec un code retour 584 ( Order number error).

Mais que faire pour l'ordre de la missive d'acquittement puisqu'il est dit : "Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges." ?

Quitte à être non conforme à la directive, je préconise un ordre à 1 et non 0.


De même, si l'ordre n'est pas un entier positif (par exemple un entier négatif), j'acquitterai négativement (NAK) avec un code retour 581 (XML syntax error, non conforming to schema) et un ordre 1.

Q5.4 est-on obligé de renvoyer une missive ?

L’émetteur d'une missive qui n'a pas reçu à temps un acquittement peut renvoyer une missive, selon la directive d'implémentation de la missive et la SMIRK Missive.
La première dit "If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent".
La seconde dit "Un système de renvoi d'une missive peut être implémenté.[...] l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans un temps supérieur aux minima définis pour la priorité de la missive peut renvoyer la missive avec un numéro d'ordre incrémenté ; il s'interdit de le faire avant ; il n'est pas obligé de le faire"

L’émetteur peut donc renvoyer une missive mais il n'est pas obligé de le faire; il n'est même pas obligé d'implémenter le système donc de proposer le service à son client.

Codes de retour du protocole SEPAmail au niveau de la couche Missive

Le protocole SEPAmail liste sur cette page (standard en version 1206) des codes en trois chiffres pour qualifier/préciser la nature de l'acquittement d'une missive.

Nous allons, dans ce billet, successivement :

• reprendre la définition générale de ces codes
• regarder l'usage de chacun des codes
• répondre à quelques questions fréquemment posées

Définition des codes d'acquittement

Les codes d'acquittement forment une nomenclature à chiffres [0-9]{3} sur trois positions :

• la classe (position 1)
• le sujet (position 2)
• le détail (position 3)

Cette nomenclature est similaire aux codes de statut du retour des protocoles HTTP, SMTP etc...

La classe peut être :

• classe 1 = non utilisé pour le moment, information
• classe 2 = succès
• classe 3 = non utilisé pour le moment
• classe 4 = erreur transitoire
• classe 5 = erreur permanente

Inventaire des codes proposés par le standard

La liste des codes d'acquittement proposés peut se schématiser en carte mentale :

Liste des codes retour proposés par la version 1206

Nous allons voir que de nombreux codes ne servent pas.

Ils ont (malheureusement) pour seul effet de perdre ceux qui veulent comprendre le protocole.

Ils sont résiduels aux expérimentations passées (et des besoins ponctuels de développeurs) et n'ont pas vocation à rester dans le standard, maintenant que l'industrialisation est en cours et les expérimentations finies.


Sujet 1 : les addresses


Ce sujet permet d'acquitter une missive nominale sur les champs de l'entête de missive A.5.1 (balise Snd) et A.5.4 (balise Rcv) exclusivement.


5.1.1     Unknown sender

L'expéditeur de la missive, comme défini par la balise A.5.1 (Snd, balises BIC et|ou IBAN) n'est pas connu par le récepteur. Ce code est répondu en complément d'un acquittement de type NAK. Le récepteur se pose la question du BIC de l’émetteur (référentiel commun) ou de la forme de l'IBAN émis, qui est le plus généralement un QXBAN.


5.1.2     Unknown receiver

Le destinataire de la missive, comme défini par la balise A.5.4 (Rcv, balises BIC, IBAN, BBAN, PAN, RIS2D) n'est pas connu par le récepteur. Cela peut concerner le BIC (référentiel commun) ou un identifiant bancaire du récepteur qui n'est pas connu par le récepteur.


5.1.3     Receiver known but out of SEPAmail scheme or ecosystem.

Le destinataire de la missive, comme défini par la balise A.5.4 (Rcv, balises BIC, IBAN, BBAN, PAN, RIS2D) est connu par le récepteur mais ne reçoit pas de missives SEPAmail sur cet ecosystème.
Ce code sert pour préciser à l'expéditeur que ce destinataire existe mais qu'il ne reçoit pas les missives SEPAmail. Il est donc inutile d'utiliser SEPAmail avec ce destinataire pour le moment, et ce, quelque soit l'application de SEPAmail et l'expéditeur.
Ce code ne sert donc pas pour refuser l'attache d'un expéditeur précis ou pour une application de SEPAmail précise.


2.1.9     Receiver known, missive forwarded

C'est le code le plus utilisé, car c'est le seul code de succès de la liste utilisable avec un acquitement positif (ACK).


Sujet 2 : la boite aux lettres


Ce sujet est ambigu car il adresse la couche échange d'enveloppe SEPAmail et non la structure de la missive.


Il est historique à l'expérimentation : lors du passage du mode canonique au mode flash (web services), les implémenteurs de l'expérimentation ont eu besoin de ces codes retours natifs au protocole d'échange SMTP, d'où ces codes concernant les adresses mails de l'enveloppe SMTP/S-MIME et la longeur des messages autorisés, au sens message SMTP et non message SEPAmail.


Mon conseil est de ne pas utiliser ce sujet dans l'acquittement d'une missive et de bien réfléchir à l'implémentation naturelle de l'échange d'enveloppe SEPAmail, quelque soit le type de contenu transporté.


Sujet 3 : les systèmes



Ce sujet traite des erreurs "dites" système, c'est à dire relevant de l'infrastructure connectée.


N.3.1     File system full

Ce code (431 ou 531) ne devrait pas être utilisé en acquittement de missive entre deux adhérents SEPAmail. Il n'adresse pas le contenu de la missive mais l'échange d'enveloppes. Il y a donc d'autres couches protocolaires pour décrire ce statut.


N.3.2     Inaccessible server

Ce code (432 ou 532) ne devrait pas être utilisé en acquittement de missive entre deux adhérents SEPAmail. Il n'adresse pas le contenu de la missive mais l'échange d'enveloppes. Il y a donc d'autres couches protocolaires pour décrire ce statut.


4.3.3     Sending date+time incorrect, and outside of the margin. (Missive has not been handled).

Ce code retour (433 ou 533) permet de traiter une incohérence d'horodatage de la missive, champs A.5.2 (balise SndDtTm) ne permettant pas d'acquitter la missive.
Si la missive peut être acquittée positivement, selon les règles de réception définies dans la directive d'implémentation , alors le bon code retour est 219 avec une précision dans le champs A.6.7 (balise RtgWarn/Code à la valeur BAD_TIME) et non un code 433 ou 533. Il n'y a donc pas de code retour possible 233, comme indiqué par la mention "Missive has not been handled".


5.3.3     Sending date+time incorrect, and outside of the margin. (Missive has not been handled).

Je ne vois pas de sens à ce code retour. Si quelqu'un voit un tel cas, Je suis preneur en commentaire d'un cas d'usage.


Sujet 4   Le débiteur



Ce sujet est une erreur de compréhension du modèle en couche proposé par SEPAmail ainsi qu'une erreur de compréhension de la notion d'application.
Il est dédié à l'application de SEPAmail RUBIS.


Je suis certain qu'il ne devrait pas être utilisé.


Le code 541 devrait plutôt être un code 512 ou 513.
Le code 249 serait un code 219.
La notion de compte de test n'a pas de sens SEPAmail et elle relève d'une confusion avec l'articulation monétique pendant l'expérimentation.


Sujet 5 La sécurité et la cryptographie



Ce sujet est important pour SEPAmail; il concerne la sécurité en général et la cryptographie en particulier, telle qu'elle est utilisée dans l'enveloppe SEPAmail ou dans la missive SEPAmail.
La cryptographie utilisée pour les connexions sécurisée des protocole HTTP, SMTP ou autres, n'est donc pas concernée par ces codes d'acquittement

5.7.2     Impossible to decrypt (key1 or key2). In fact, since the decryption of the S-MIME envelope cannot be processed, the embedded missive cannot be read and acknowledged. Thus, the proper behaviour in this case will be avoiding any response to the sender.

Ce code n'a pas de sens au niveau missive et ne permet pas d'acquitter dans les conditions du protocole SEPAmail. Il ne peut donc pas être utilisé.


5.7.3     Unsupported algorithm or security function

Ce code est utilisé quand un algorithme ou une fonction de sécurité non autorisé par le protocole SEPAmail sont utilisés pour l'enveloppe SEPAmail.
Il est naturel, par exemple, si sha1 est utilisé alors que la directive d'implémentation de la cryptographie exige a minima sha256, d'acquitter toute missive enveloppée à l'aide de sha1 avec un tel code.


5.7.4     Integrity error

Ce code est utilisé s'il y a une erreur d'intégrité dans l'utilisation des fonctions de sécurité. Cela peut être une somme de contrôle non intègre, une clé périmée, une signature lue, mais non référencée, une incohérence entre l'adresse mail utilisée par SMIME et l'adresse utilisé dans l'entête SMTP ou l'échange SMTP.


Sujet 8 Contenu



Ce sujet traite de l'analyse du contenu de la seule missive, avec les quelques adhérences résiduelles aux couches message et enveloppe.


5.8.1     XML syntax error, non conforming to schema

Ce code est utilisé quand une missive n'est pas conforme au schéma XML sepamail_missive.xsd.


5.8.2     Missive contents incoherent

Ce code est utilisé quand une missive est conforme au schéma XML mais n'est pas conforme à la directive d'implémentation de la missive dans le cadre de son utilisation.
C'est le code d'erreur utilisé quand une missive de type SMAPI ou de service est utilisé entre deux adhérents SEPAmail.


5.8.3     Invalid missive identifier

Ce code est spécifique à l'identifiant de la missive, notamment si celui-ci est invalide comme doublon ou ne respecte pas la règle de génération de cet identifiant, règle que j'ai commentée dans un précédent billet.


5.8.4     Order number error

Ce code est utilisé quand le champ A.3 (balise MsvOrd) n'est pas conforme à la règle d'usage.


5.8.5     Version not supported

Ce code est utilisé si la version utilisée de la missive SEPAmail n'est pas mise en œuvre.


5.8.6     Corrupted contents or virus detected. In fact, since the detection of a corrupted content may be prior to the extraction of the embedded missive due to infrastructure constraints, this missive may not be acknowledged to the sender.

Ce code fait l'objet d'une ambiguité portée par la protection de type pare-feu applicative des infrastructures qui ne respectent pas, la plupart du temps, le modèle en couche de la famille TCP/IP, afin de mieux protéger le système d'information. Ces systèmes ne répondent pas correctement sur les couches impactées, afin de ne pas donner lieu à des dénis de service.

Voici des cas d'usage qui pourraient utiliser ce code :

• utilisation d'un caractère UTF8 non autorisé par SEPAmail
• contenu des champs binaires (CDATA) suspect après passage d'un anti-virus
• somme de contrôle non cohérente avec le contenu

 

FAQ sur les codes d'acquittement 

 

Peut-on renvoyer un code retour ne contenant qu'une partie de l'information, par exemple un code de classe 5 sans sujet ni détail ?

Rien n'interdit de spécifier seulement la classe, par exemple 2 ou 4 dans préciser le sujet et le détail d'un code d'acquittement.
Le code d'acquittement n'est pas obligatoire.
Seul l'est le statut de l'acquittement, (balise AcqSta)

Pourquoi ne pas supprimer les codes d'acquittement obsolètes ?

Bonne question. Cela devrait être fait après la fin de l'expérimentation.

Lors des expérimentations et avant le passage en conformité des différentes plateformes des adhérents, il a fallu composer avec différentes version logicielles des implémentations et laisser les codes d'acquittement, notamment ceux liés à RUBIS.

Peut-on inventer des nouveaux codes ?

Pour votre usage interne, j'imagine que oui.

Je conseille de les proposer à la communauté si vous souhaitez partager leur interprétation avec d'autres acteurs SEPAmail.

Comment déclarer SEPAmail à la CNIL si un code d'acquittement donne de l'information sur mon client ?

Il est difficile de répondre de façon générique à cette question.

La plupart des codes proposés sont généraux.

Dans une messagerie, il y a toujours une information transportée et bouclée... donc il y aura de l'information sur l'expéditeur et le destinataire partagée avec les 4 acteurs mis en jeu.

L'intérêt de SEPAmail est que cette relation à 4 est couverte par des contrats clairs entre chaque partie : le contrat adhérent-utilisateur et le contrat d'adhésion SEPAmail.

Il ne faut pas non plus confondre la couche SEPAmail et les applications de SEPAmail, comme RUBIS ou GEMME, qui devraient se déclarer séparément.

Consulter la CNIL ou votre CIL (correspondant informatique et liberté) me paraît un bon préalable pour déclarer.

A quoi sert le champ description de l'acquittement ?

Ce champ sert à mettre une information permettant à l'émetteur de la missive nominale d'analyser plus finement le pourquoi d'un code retour.

Il est libre et doit servir la messagerie sans desservir le client final.

Il est dédié à une analyse humaine et non automate.



Comment peut-on acquitter plusieurs fois une missive nominale ? Si c'est le cas, comment savoir quand le processus d'émission peut-être considéré comme terminé ?

La possibilité d’acquitter une missive en plusieurs fois est évoqué dans la SMIRK MIS1202 et clairement dans la directive d'implémentation de la missive, en donnant un exemple d'acquittement multiple, qui utilise de plus un code 249, code que je proscris un peu plus haut.

Cet acquittement multiple provient d'une demande de pouvoir relier SEPAmail à une chaine de traitement bancaire batch pour RUBIS... là encore, il y a confusion entre les applications de SEPAmail (structurant des dialogues de messages) et la messagerie SEPAmail (mécanisme de routage, d'adressage, d'authentification des partie, de sécurité du transport).

L'acquittement multiple pose aussi une problématique claire de finalisation du processus d'émission et l'implémentation de la fin du processus dépend de l'interprétation des temps de réponse pour acquitter... Est-ce un temps de réponse pour le premier acquittement ou pour le dernier ?

Selon ma compréhension du protocole, l'expérience de l'implémentation, des différents usages de ce protocole, le système d'acquittement devrait être simplifié en proposant clairement que les statuts ACK et NAK soient des statuts finaux (sans possibilité pour le récepteur d'acquitter de nouveau ensuite).

Le système de renvoi sert pour l'émetteur à dire "alors, vous me répondez ?"... Certains récepteurs désirent dire :  "j'ai reçu mais je n'ai pas encore traité, donc pas besoin de renvoyer."

Quelqu'un m'a un jour dit qu'on ne pouvait pas vraiment distinguer si la missive n'était pas arrivée ou si le récepteur n'avait pas encore acquitté.

Ce n'est pas vrai dans l'absolu et vrai dans la pratique de certains systèmes d'information.

Dans l'absolu, le protocole d'échange SMTP (et par analogie d'implémentation pour HTTP+SOAP) permet bien de savoir si le système d'information du récepteur a reçu le paquet d'information... un certain nombre de codes retour sont bien prévus et implémenté par toutes les applications MTA, quand elles ne sont pas bridées par un pare-feu applicatif.

Dans la pratique, les système d'information ne sont pas parfaits et leur exploitation peut perdre des messages, et ce la, pour toute sorte de raison.

La proposition d'ajouter un statut d'attente (WAIT) ne résoudra pas le problème de fond. Il faut que l'acquittement soit simple à mettre en œuvre sur la couche missive, ne se confonde pas avec la couche message et applicative de la messagerie SEPAmail.

Il faudrait donc (et cela sera à mon avis forcément le cas dans la version industrielle dès qu'il y aura de gros flux) que les adhérents de SEPAmail, qui mette en œuvre le réseau privé SEPAmail, s'engage à acquitter une seule fois dans les temps de la priorité de la missive.
Les mécanismes de renvoi et d'escalade sont mis en œuvre pour garantir cette qualité de service. Je milite donc rester simple sans présumer des systèmes d'information mettant en œuvre le protocole SEPAmail.

SEPAmail : la portée de l'acquitement

Le protocole de messagerie SEPAmail comprend un acquittement des messages échangés. Cet acquittement est réalisé par le fournisseur de l'accès à SEPAmail (l'adhérent) pour le compte du destinataire dès réception du message.
Cet acquittement est obligatoire dans tous les cas pour tous les fournisseurs d'accès à SEPAmail, quel que soit l'expéditeur et le destinataire, dans les cas où l'acquittement est possible.

Ces règles sont décrites dans la directive d'implémentation de la missive.

Cet acquittement permet à l'expéditeur du message, ainsi qu'à son fournisseur d'accès à SEPAmail d'être assuré :

• de la bonne réception du message émis (contenu dans une missive nominale), réception, horodatage, validité, authentification des fournisseurs d'accès et de sécurité SEPAmail
• du routage qui sera réalisé vers le destinataire du message (défini par l'entête de la missive)
• de la capacité de distribution du message au destinataire

On remarque que la prise en charge des fonctionnalités autour du message ne fait pas partie de la fonction de l'acquittement.


L'acquittement se présente sous la forme d'un statut succès (ACK) ou échec (NAK) avec, facultativement, un code de retour pour expliquer le statut. Ces codes retour sont décrits ici et sont tous valides sauf ceux correspondant au sujet 4, à savoir les codes 541, 248, 249 (ces trois codes ont été utilisés dans le cadre de l'expérimentation mais ils ne correspondent pas à des retours possibles pour une messagerie; ils sont liés à l'application de SEPAmail RUBIS).

Comme pour tout protocole en couche, il est important que la messagerie SEPAmail ne se substitue pas aux couches au dessus et en dessous (en amont et en aval du traitement) pour son action.

Prenons un exemple dans le cadre d'une demande de règlement RUBIS pour bien comprendre la portée de l'acquittement.

Supposons qu'une personne A veuille transmettre à une personne B une demande de règlement.
Les fournisseur d'accès a SEPAMail de A (FasA) et B (FasB) leur proposent le service RUBIS.

Voici trois cas d'usage de réception par FasB de la missive nominale contenant la demande de réglement :

• cas 1 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivationRequest n'étant pas conforme au schéma XML
• cas 2 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivationRequest conforme au schéma mais pas à la directive d'implémentation RUBIS de ce message
• cas 3 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivtationRequest conforme au schéma et à la directive d'implémentation RUBIS du message avec une seule demande de paiement en trois fois que FasB ne propose pas à son client B

Le cas 1 est le plus simple à comprendre et l'acquittement SEPAmail permet de traiter ce cas quelque soit le message contenu dans une missive nominale, c'est un acquittement NAK avec un code retour de sujet contenu et de code 581 "XML syntax error, non conforming to schema".
Remarque : on voit par ce retour que SEPAmail permet d'acquitter la présence d'un message conforme (au sens des schéma XML) au sein de la missive, ce qui dépasse en fontionnalité l'accusé de réception postal.

Le cas 2 pourrait être, par exemple, un champ  PaymentMethod à CHQ alors que ce champs, au sein du pain.013 est annoncé dans la directive d'implémentation comme "Mandatory. The only value currently accepted here is "TRF". Note : if the OtherPmtMtd field, in the non-ISO part, is used, this field will be ignored"ou un élément ChargeBearer qui ne serait pas à la valeur "SLEV" comme exigé par l'implémentation de RUBIS.
Ce cas ne relève pas de la messagerie SEPAmail puisque le message PaymentActivationRequest est intègre du point de vue de son schéma.
C'est l'application RUBIS de SEPAmail qui doit (ou peut) répondre. Si FasB pense que c'est une bonne idée dans sa relation avec FasA de boucler le processus, FasB devrait donc préparer un PaymentActivationReport négatif avec une mention de non prise en charge des ces options de la demande de règlement pour non conformité à la norme RUBIS.

Le cas 3 est cas de conformité à la norme SEPAmail et à la norme RUBIS non pris en charge par FasB. FasB est donc peut-être dans l'impossibilité de transmettre le message et prendre en charge la demande fonctionnelle associée à ce message.
Selon les cas de la relation et du contrat que FasB et B ont signé, FasB peut:

• transmettre le message pour seule prise en compte du signifiant,
• répondre pour le compte de son client de façon négative en motivant le refus
• ne rien faire

Dans les cas 2 et 3, la missive nominale a été acquittée normalement (code retour 219) car la missive a bien été reçue conforme et relayée en terme de messagerie.

Certains sont tentés de reporter l'impossibilité fonctionnelle du fournisseur d'accès à SEPAmail de transmettre le message (ce message ne répond pas à la norme RUBIS ou le cas n'est pas traité par le fournisseur d'accès du destinataire) au sein de l'acquittement de la messagerie.
Il ne faut pas céder à cette tentation, au risque de confondre la couche SEPAmail (messagerie) et la couche RUBIS (application de SEPAmail). En faisant cela, on dénature l'acquittement et son intérêt en terme d'accusé réception.

SEPAmail.eu pourrait, à mon sens, pour lever les ambiguités sur ce sujet :

• préciser des cas d'usage, pour bien expliquer l'interprétation qui doit être faite de la norme autour de l'acquittement
• séparer la norme de messagerie SEPAmail de chacune des normes des applications utilisant SEPAmail
• enlever les scories due à l'expérimentation, comme les codes retour d’acquittement de sujet 4
   

Vocabulaire SEPAmail : la missive nominale

La missive

Une missive SEPAmail est un contenant regroupant un message et des propriétés d'adressage et de priorité au sein du réseau des utilisateurs SEPAmail, comme précisé dans un précédent billet.
Cette couche intermédiaire entre l'enveloppe et le message permet de rendre confidentielles ces propriétés et de ne conserver sur l'enveloppe que les seules informations nécessaire au bon acheminement sur le réseau IP de l'ensemble {enveloppe>missive>message}

La missive nominale

Une missive est dite nominale lorsqu'elle transporte un message émis par un utilisateur SEPAmail destiné à un autre utilisateur SEPAmail (ou lui-même).

Le cœur de métier du dispositif SEPAmail est donc de transporter ces missives nominales.

Pourquoi distinguer des missives nominales ?

Si on veut garantir la bonne distribution d'un message, il faut que le destinataire puisse accuser de façon certaine la bonne réception et sa capacité à traiter le message.
Il faut donc un mécanisme pour distinguer le message initial et l'accusé de réception afin d'appliquer les bonnes règles (priorité, émission, réception, contrôle).

Comment cela fonctionne ?

La missive est structurée en xml, ce qui permet:

• en exploitation une validation rapide et simple
• une évolution plus facile et la possibilité de gérer plusieurs versions

La missive est orientée adressage et routage dans le réseau (privé) SEPAmail.
Elle est exclusivement dédiée à ces fonctions.

Le type nominal de la missive signifie qu'elle contient un message à relayer.

Les autres missives

Il y a dans la norme d'autres types de missives:

• la missive d'acquittement, permettant l'acquittement des missives nominales
• la missive de service, permettant d'encapsuler un dialogue client/serveur dans l'espace de confiance de l'adhérent avec son utilisateur
• la missive d'interfaçage (SMAPI), permettant d'encapsuler des accesseurs/constructeurs API avec un SMart ou un SMile

Vocabulaire SEPAmail : l'acquittement

Qu'est-ce que l'acquittement dans SEPAmail ?

L'acquittement SEPAmail permet de mettre en place une chaîne d'accusés de réception pair à pair depuis l'expéditeur du message jusqu'au destinataire du message en passant par les relais d'acheminement (les adhérents SEPAmail).

L'accusé de réception SEPAmail est réalisé sous la forme d'une missive de type acquittement, en réponse à une missive nominale qui contient l'information initiale à transmettre.

Cet accusé possède les propriétés suivantes :

• rien ne distingue une enveloppe SEPAmail contenant une missive d'acquittement
• l'acquittement est désynchronisé de la réception, avec une garantie d'acquittement selon la priorité de l'envoi
• l'acquittement est garanti grâce à un engagement des parties, ainsi qu'un mécanisme de renvoi et d'escalade
• l'acquittement est horodaté pour la partie réception du message initial et pour son envoi
• l'acquittement garantit la vérification des signatures, la vérification de l'intégrité du message initial

Certains parlent de cet acquittement comme un acquittement technique, ce qui amène de la confusion car cela induit que c'est un accusé de type infrastructure et automate, comme ceux des protocoles réseau, ce qui n'est pas du tout le cas.

Cet acquittement est fondamental dans le protocole SEPAmail car c'est lui qui va permettre à chacun des adhérents de proposer du service à son client, notamment des services juridiques, d'huissier, de qualité, de relance automatique etc...
Cet acquittement est un acquittement non technique, automate dans la plupart des cas, et enfin fonctionnel pour le métier de messagerie électronique. Il est partagé par toutes les applications SEPAmail et fait partie des composants de sécurité de la messagerie SEPAmail.

Les comparaisons avec l'accusé de réception postal.

Le mécanisme de recommandé avec accusé/réception souffre de défauts connus :

• il faut noter le numéro de lettre recommandée sur le courrier ce qui confond la couche message et la couche enveloppe
• n'importe qui peut envoyer un recommandé au nom de quelqu'un d'autre car il n'y a pas vérification de l'identité à l'envoi
• si le recommandé n'est pas accepté, il faut envoyer une lettre simple en même temps pour garantir que le destinataire a bien reçu le courrier
• le facteur, en remettant le courrier, attend une signature pour générer l'accusé de réception, ce qui provoque une attente due à une synchronisation nécessaire pour garantir l'accusé réception et souvent une délégation de signature au service courrier
• le transporteur est en même temps relais d'acheminement pour les deux parties, sans contrat commercial clairement établi entre les parties et le transporteur

L'acquittement SEPAmail a été pensé pour dépasser tous ces défauts.
Nous y reviendrons peut-être dans un prochain billet.

Pour aller plus loin

On trouvera sur la documentation de SEPAmail:

• les règles protocolaires sur l'acquittement.
• les règles protocolaires sur le renvoi de missive nominale.

SEPAmail est une messagerie structurée

La messagerie électronique a changé la façon de communiquer dans l'entreprise.
D'aucuns lui voient un avenir sombre car il y aurait "trop de messages, trop de messages illisibles, trop de messages moches" (marc herbert).


Le dispositif SEPAmail diffère d'une messagerie classique par la structuration imposée:

• structuration du contenu du message (le signifiant), qui doit se conformer à un schéma prédéfini (schémas XML)
• structuration du type de message, qui doit appartenir à une liste prédéfinie
• structuration de la séquence de messages, qui est définie au travers de règles métier (directives d'implémentation)
• structuration de la partition des messages en écosystèmes
• structuration de la séquence d'échange des missives avec son mécanisme d'acquittement (accusé de réception SEPAmail)

SEPAmail profite donc des qualités de la messagerie électronique (rapidité, simplicité, coût, ergonomie, usage répandu) tout en structurant les échanges pour y ajouter des possibilités d'automatisation, de dématérialisation, de sécurité.

On peut voir SEPAmail comme une messagerie structurée authentifiant tous les acteurs (relais et utilisateurs) autour d'un signifiant métier fondé sur l'iso 20022.

Vocabulaire SEPAmail : enveloppe, missive et message

La double encapsulation

SEPAmail met en œuvre une double encapsulation :

• le message SEPAmail est encapsulé dans une missive SEPAmail
• la missive SEPAmail est encapsulée dans une enveloppe SEPAmail

Le message SEPAmail

Le message contient le signifiant à échanger entre les utilisateurs SEPAmail expéditeur et destinataire.
Il appartient forcément à un type défini (voir le type MessageType du schéma XML type_sepamail_message.xsd).
Un message est toujours une information structurée dans un format XML selon un schéma XMLSchema publié dans un espace de nom dédié de la communauté SEPAmail.

La missive SEPAmail

La missive SEPAmail sert à :

• l'adressage,
• l'identification des destinataire et expéditeur
• l'acheminement du message et notamment son horodatage

La missive est aussi construite dans un format XML.

La missive respecte toujours la structure suivante :

• un identifiant
• un type
• un ordre
• une priorité
• un entête contenant lui même l'adressage
• l'information à échanger (le message, l'acquittement, la commande, le résultat...) et une signature facultative de cette information si besoin

La missive peut être vue comme le support de toutes les indications d'acheminement de l'information.

L'enveloppe SEPAmail

L'enveloppe SEPAmail garantit :

• l'authentification du relais d'acheminement,
• la confidentialité de la missive,
• le transport de la missive sans révéler son adressage.

Pour cela SEPAmail utilise une enveloppe SMTP+S-MIME comme container de la missive chiffrée, la signature numérique de l'expéditeur, un adressage de type SMTP (par exemple [ecosystem]@[BIC].sepamail.eu) et une priorité.
Ainsi, cette enveloppe peut être envoyée et relayée telle quelle sur le réseau de la messagerie électronique (mode canonique) ou par un service web, même basique (mode flash).

Remarque : il existe aussi une enveloppe fichier afin de permettre le transport de plusieurs missives à la fois au sein d'un système d"information quand il n'y a pas de besoin d'authentification et de confidentialité. Pour bien distinguer ces deux enveloppes, seule l'enveloppe SMTP+S-MIME est appelée enveloppe SEPAmail.

Pour aller plus loin

Nous préciserons dans d'autres billets les différents types de messages et de missives et leurs usages.
Sur ces sujets, nous conseillons la lecture de :

• la SMIRK missive
• la SMIRK message

Vocabulaire SEPAmail : la messagerie SEPAmail, les applications SEPAmail

Il ne faut pas confondre la messagerie SEPAmail et les applications SEPAmail qui utilisent la messagerie SEPAmail.

 

La messagerie SEPAmail

La messagerie SEPAmail est un dispositif permettant à deux entités économiques européennes de s'échanger de l'information de façon sécurisée.
Ce dispositif est mis en place par un réseau d'adhérents, essentiellement des banques européennes.
Il repose sur des standards de l'internet (IP, DNS, SMTP, S/MIME, syslog).
Un modèle en couches (enveloppe/missive/message) est proposé comme standard par la communauté SEPAmail. Ce modèle permet de spécifier de façon assez élégante des règles autour de l'échange, de l'adressage, du routage et de la sécurité.

 

Les applications SEPAmail

Les applications SEPAmail ont des noms de pierres précieuses.
A ce jour, on compte 7 applications :

• AGATE, la pièce jointe générique
• DIAMOND, la vérification d'identifiant bancaire
• GEMME, le mandat de prélèvement
• IOLITE, la transmission de facture
• JADE, l'avis de virement
• JASPE, la signature de document
• RUBIS, la demande de règlement

Une application SEPAmail utilise la messagerie SEPAmail pour échanger des messages structurés entre les parties dans un dialogue de type question/réponse avec la possibilité de joindre des documents. Comme la banque est un relais de cet échange, elle peut, si le contrat avec son client le précise, enrichir les flux et automatiser des opérations, notamment de paiement (carte, virement, prélèvement).

Avec cette messagerie sécurisée et des applications partagées entre les adhérents SEPAmail, la dématérialisation, l'automatisation et la sécurisation sont beaucoup plus aisées à mettre en œuvre pour les entités économiques.

La mise en place de SEPAmail  dans les relations entre les entités économiques présage ainsi des réductions de coûts très importantes.

 

Pour aller plus loin :

• présentation de la messagerie SEPAmail
• présentation de la notion d'application (SMIRK APP1103 en discussion)