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)
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.
