Outils personnels

Standards: SMIRK MIS1202, the missive in the interbank exchanges

De documentation SEPAmail.

Cette page est une traduction de la page SMIRK MIS1202, la missive dans les échanges interbancaires et la traduction est complétée à 99 % et à jour.

LogoScheme.png

document type: comments request
the missive in the interbank exchanges

code SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail. MIS1202 version 1.1 of June 26, 2012


Sommaire

Introduction and overview

The missive is the only entity allowing the exchange of information in the SEPAmailmessagerie bancaire sécurisée. system. The missive has the envelope role for confidential data. In order to properly route the different information of the system, four types of missives have been defined:

  • the nominal missive, routing a message
  • the acknowledgement missive, with mainly a protocol objective

as well as:

  • the service missive, allowing a dialog of "command - answer" type between two systems, reserved to the competitive space outside of the SEPAmailmessagerie bancaire sécurisée. network participants. This missive is therefore not used for exchanges between participants of the SEPAmailmessagerie bancaire sécurisée. network
  • the SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. missive (SEPAmailmessagerie bancaire sécurisée. API), that can solely be reached in an intrabank context, and allowing a SEPAmailmessagerie bancaire sécurisée. service provider to provide a direct access to some elements of its platform.

The SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. missive is at the border of the SEPAmailmessagerie bancaire sécurisée. standards: its existence is part of the standards but the exact content of SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. messages is up to service providers.

SEPAmailmessagerie bancaire sécurisée. uses the missive to:

  • information addressing (who is the reveiver, who is the sender)
  • the information routing (how I forward the information)
  • the information receipt (has the information arrived)
  • the information integrity (is it the correct information)
  • the authentication of parties (are the sender and the receiver the ones they indicate they are)
  • the time stamping of the information (when was the information sent and received)

Principles

The missive is an XML flow complying with the diagram sepamail_missive[1], that is part of the specifications of the system. This element is used to transport all kinds of messages or other contents. It plays the envelope role and may be forwarded in several ways.

The missive may be of two types:

  • a nominal missive, envelope for any kind of content (but especially for a SEPAmailmessagerie bancaire sécurisée. message),
  • an acknowledgement missive, allowing to notify the receipt of a nominal missive.

Note: The service missive is a notion that should not be used in the interbank space. It is therefore not included in this SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail.. A lexicon of terms that are used is present on documentation of the SEPAmail Community[2].

The routing

The routing uses a "mail" type addressing on the domain sepamail.eu. The name of the sepamail.eu is managed by the SEPAmailmessagerie bancaire sécurisée. scheme under the format: <ecosystem>@<bic>.sepamail.eu or <ecosystem>@<xx.scheme>.sepamail.eu where:

  • <ecosystem> is a valid SEPAmailmessagerie bancaire sécurisée. family of the referential applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail@SCHEME
  • <bic> is a valid BICBank Identifier Code, norme ISO 9362:1994 if the referential BICBank Identifier Code, norme ISO 9362:1994@SCHEME
  • <xx.scheme> represents a network node owned and managed by the scheme, for instance fr.scheme for the French QXOOBureau local opérationnel du SCHEME (QX Operational Office). To understand the scheme organisation, refer to the SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail. on its organisation SMIRK ORG1110

The routing is performed by the SEPAmailmessagerie bancaire sécurisée. participants in the scheme with unattended machines implementing the following routing rules:

Routing rules at the receipt

  • A Participant only accepts missives for BICs it represents. Therefore, a Participant does not act as a relay of another Participant.
  • A Participant only accepts missives coming from a BICBank Identifier Code, norme ISO 9362:1994 linked to a SEPAmailmessagerie bancaire sécurisée. Participant. The SEPAmailmessagerie bancaire sécurisée. nekwork is therefore a network reserved solely to its Participants et closed to the rest of the world.

Routing rules for sending

  • A Participant sends flows in the SEPAmailmessagerie bancaire sécurisée. network only to a SEPAmailmessagerie bancaire sécurisée. Participant for a BICBank Identifier Code, norme ISO 9362:1994 that is declared and valid in the referential BICBank Identifier Code, norme ISO 9362:1994@SCHEME.

The acknowledgement of a missive

The acknowledgement aims at informing the sender of the receipt, good or bad, of the missive that is sent and of a time stamping of this receipt.

It is the sender that manages the forward of information and not the receiver. The acknowledgement is mandatory and systematic. It does not depend on the sequence historic.

The acknowledgement class does not depend on the controls inmplemented by the receiver. The return codes are listed in specific implementation guidelines.

The acknowledgement is performed with the following rules:

  • only nominal missives are acknowledged
  • any nominal missive received (whatever its order) must be acknowledged
  • the acknowledgement must be performed in compliance with the priority and the maximum time limit of the priority.

The sequencing

The natural sequence of an exchanges of missives is:

séquencement des missives
  • a Participant A sends a nominal missive to a Participant B from a missive source system
  • a Participant B receives the nominal missive from the Participant A in a missive target system
  • the Participant B sends one or more acknowledgement missives to the Participant A as a response to th nominal missive
  • the Participant A receives the acknowledgement missive(s).

Below are listed the sequencing rules to be implemented:

  • the receiver of any received nominal missive must perform the acknowledgement of this nominal missive by at least one acknowledgement missive
  • no missive of another type than "nominal" or "acknowledgement" is sent
  • no missive of another type than "nominal" is acknowledged"
  • no "acknowledgement" missive is sent without having previously received a "nominal" missive

Resending a missive

A system to resend a missive may be implemented.

It is performed as follows:

  • it is implemented only with nominal missives,
  • the missive is resent with an order incremented by 1; the sender cannot change the content of the missive that is resent, except the order number
  • the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels signature of the sender is therefore different.

If a nominal missive has not been acknowledged after a while, the following rules are implemented:

  • the sender of any nominal missive for which no acknowledgement has been received after the time limit of mimimum defined for the missive priority, may send again the missive with an incremented order number; it cannot do it beforehand; it is not obliged to so do
  • the resending of a missive cannot be performed after a period of time, as defined in the table below, after the sending of the previous missive
  • the sender of any nominal missive for which an acknowledgement is not received in the maximum timing authorised for the priority of the missive and that has resent at least once the missive may then implement the planned process to escalate; it cannot do it beforehand; it is not obliged to do it.

The system to increment the order of the nominal missives is not intended to allow to forward several times a same missive to receive different acknowledgements. This system is only used to receive an acknowledgement if it has not been received.

The following rules are therefore applied:

  • a system to receive and control the acknowledgements must be implemented,
  • resending a missive is not possible if it has already been acknowledged, except if the acknowldegement class is 4 (temporary error).
Waiting time before resending depending on the missive priority
Priority Acknowledgement maximum time limit Minimum time limit before resending Maximum tile limit before resending Maximum resending number
1 the highest 20 sec 30 sec 1 min 3
2 high 3 min 5 min 10 min 5
3 normal 4 h 4 h 8 h 4
4 low 12 h 12 h 24 h 3
5 the lowest 48 h 48 h 96 h 3

The resending time limits are reset to zero each time the missive is resent. Therefore, if a missive with a "high" priority is sent at T time for the first time (order 1), the missive of order 2 can be sent between T+5min and T+10min. If it is sent at T+7min, the missive of order 3 (if no acknowledgement is still received of course) can be sent between T+12min and T+17min, etc...

The maximum acknowledgement time limit, the minimum time limit before resending and the maximum number of resendings that are mentionned here, are default values. If two Participants sign a bilateral agreement, they are free to agree on different time limits and/or on a higer number of resendings.


Waiting time before escalation depending on the priotity of the missive
Priority Minimum time limit before escalation
1 the highest 10 min
2 high 30 min
3 normal 16 h
4 low 36 h
5 the lowest 120 h

Reminder: this time limit is calculated starting when the first missive is sent (order 1), it is not reset to zero each time the missive is resent, contrary to the resending time limits described above.

The escalation process

If a missive is not acknowledged, even after having been resent, the participant may process an escalation planned by the scheme as soon as a minimum time limit is reached after the last resending (refer to the table below).

This escalation is specified by the Scheme in a specific SMIRK.

The content

According to the SEPAmailmessagerie bancaire sécurisée. business rules, a missive necessarily includes:

Contenu facultatif et obligatoire d'une missive
  • a unique identifier,
  • a type,
  • a presentation order,
  • a header,

and depending on the missive type:

  • an acknowledgement for an acknowledgement type missive,
  • a SEPAmailmessagerie bancaire sécurisée. message for a nominal type missive,

and as an option:

  • a signature of the message, which should not be mixed up with the signature of the message within the SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») envelope. This signature is essentially used to provide the capability to add an electronic signature of the signer, customer of the bank and sender of the message.

It is important to note that, from the strict point of vue of the compliance to the XML schema, the "message" and the "acknowledgement" sections are optional (refer to the next diagram).

The header of the missive follows three principles:

  • the symmetry principle between the receiver and the sender of the message, as both may have the two functions
  • the priority principle which allows each entity to manage the peak by prioritizing the flows
  • the principle of integrity of the information generated by the unattended machines; this principle is ensured by a set of controls on the content for which the integrity check is required

The envelope

The missive is integrated in an SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »)-S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels envelope. This envelope includes:

  • headers:
    • FROM, mail address such as specified in this document, valid with a domain name declared in the DNSDomain Name System, service permettant d'établir une correspondance entre une adresse IP et un nom de domaine<ref name="dns">http://fr.wikipedia.org/wiki/Domain_Name_System</ref>
    • TO, mail address such as specified in this document, valid with a domain name declared in the DNSDomain Name System, service permettant d'établir une correspondance entre une adresse IP et un nom de domaine<ref name="dns">http://fr.wikipedia.org/wiki/Domain_Name_System</ref>
    • X-priority, priority according to the specification of this document
    • SUBJECT empty be default, without significtive information on the content of the message
  • a body integrating again two parts:
    • the missive, enciphered with the private key of the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels certificate linked to the FROM address
    • a S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels signature, mandatory

Modèle:Note: the missive must be enciphered in any case, even for a flash route (webservice on an SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») layer), in order to allow a non adhesion of the production applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail layers of the SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») layers and of its transport.

The security: authentication, confidentiality and time stamping

The security is ensured at different levels:

  • the authentication of both parties
  • the confidentiality of the forwarded information
  • the time stamping of the processes of the missives sending and receiving

SEPAmailmessagerie bancaire sécurisée. uses asymmetric encryption processes.

Participants are sure to have access, in a secure way, to the public keys of each Participant.

The authentication of the sender (SEPAmil Participant)is then ensured by a signature of the condensate of the whole content of the missive with the private key of the sender. The receiver will then be able to check that the condensate of the missive it has generated is the same than the one of the signature it has deciphered.

The confidentiality is ensured by the encryption of the missive by the sender with the public key of the receiver. Therefore, the receiver will be the only one able to decrypt the flow with its private key.

The missive is time stamped both for the sending and the receipt by a time reference of date/time type. The detailed time stamping principles that apply to SEPAmailmessagerie bancaire sécurisée., issued from best practices of the FNTC [3], sont décrits dans cette page.

If a time stamping of type "signed time countermark" is needed, this time stamping is then performed on the SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») envelope (and not only the missive) by a certified third party entity right before the sending or right after the receipt.

The exchange protocol of the missives

la place des protocoles d'échange dans l'architecture protocolaire

The exchange of missives is natively performed on the IP network via the TCP transport layer.

On these layers, SEPAmailmessagerie bancaire sécurisée. implements two routes with two different communication ptotocols:

  • SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »)
  • HTTPS+SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML


Modèle:Note: this exchange gets implementation guidelines and is outside of the standards context of this document.

Modèle:Note: a study is currently ongoing to enable a flash route based on HTTPHyperText Transfer Protocol+RESTREpresentational State Transfer, architecture distribuée simple, n'utilisant pas d'états<ref>http://fr.wikipedia.org/wiki/REST</ref>

The service quality

The service quality is defined in a separate document [4].

Processing

The functional diagrams of the receipt and of the sending of a missive are described below. Unattended machines of Bank Participants must comply with those diagrams.

Actions on data to be performed are in blue, tests in green.

The operations follow each other according to a time sequence described from the top to the bottom.


Receipt of a nominal missive

la séquence fonctionnelle autour de la réception de missive

Receipt of an SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») envelope with the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels format

The receiver of the missive receives envelopes at the format S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels, whatever channel this envelope comes from (SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML or SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »)).

Check of the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels integrity

It is necessary to check that the format of the received envelope is S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels.

The following elements must also be present:

  • the FROM field filled in
  • the TO field filled in
  • one part enciphered or not
  • a signature with the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels format

Modèle:Note: the SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») subject may be absent or empty.

Extraction of the MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels header and of its two parts

The following elements are extracted: the FROM address, the TO address and the two parts attached to the envelope, usually the XML content of the missive and a signature of this content.

Check of the BICBank Identifier Code, norme ISO 9362:1994

It is necessary to extract the sub-domains of the FROM and TO addresses.

These two sub-domains must be those of a BICBank Identifier Code, norme ISO 9362:1994 included in BICBank Identifier Code, norme ISO 9362:1994@SCHEME.

The one corresponding to the receiver (TO) must also be on the BICs linked to the receiving Participant in the participant@SCHEME referential.

Check of the ecosystem

The ecosystem provided by the mail address must be a set of messages managed by the SEPAmailmessagerie bancaire sécurisée. network. It must be part of ecosystem@SCHEME.

Decryption

The first part of the MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels envelope is encrypted (Content-Type: multipart/encrypted) and must therefore be decrypted with the private key of the receiver (BICBank Identifier Code, norme ISO 9362:1994 extracted from the TO address) (protocol defined by the "protocol" attribute of the "Content-Type header). The decrypted chain is considered as the missive to check.

Calculation of the condensate of the missive

A condensate of the content of the missive is calculated based on the method declared in the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels characteristics (micalg attribute of the Content-Type header).

Check of the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels signature of the sending Participant

The signature of the SEPAmailmessagerie bancaire sécurisée. sending Participant is checkedby comparing the condensate previously calculated with the result of the signature decryption.

Check of the XML compliance

The missive is an XML document for which we check it is correctly created (correct syntax)[5].

Check of the XML validity

The missive is an XML document fow which the following checks are performed:

  • it includes a reference to the SEPmail name space,
  • it is valid (it validates the XML schema that it references).

Header extraction

The header is extracted from the missive in order to allow the following checks.

Time stamping

The missive is time stamped when received, which means the XML content is enriched by filling in the field « RcvDtTm » of the missive header with the date and time of the system.

Check of the Rcv field

The Rcv field includes at least:

  • an identifier of a SEPAmailmessagerie bancaire sécurisée. user (usually a bank identifier IBANInternational Bank Account Number, norme ISO 13616:2003, PANacronyme de Primary Account Number ou numéro de carte bancaire, QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code)....),
  • an identifier of the SEPAmailmessagerie bancaire sécurisée. Participant (BICBank Identifier Code, norme ISO 9362:1994 or SCHEME entity code)

This identifier must correspond to a valid user of the SEPAmailmessagerie bancaire sécurisée. service.

It must represent a active user in one of the identifiers referentials managed by the Participant receiving the missive: QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code).@BICBank Identifier Code, norme ISO 9362:1994, IBANInternational Bank Account Number, norme ISO 13616:2003@BICBank Identifier Code, norme ISO 9362:1994, PANacronyme de Primary Account Number ou numéro de carte bancaire@BICBank Identifier Code, norme ISO 9362:1994.

Acknowledgement

The acknowledgement involves sending a missive with rules that have been defined above.

Internal routing of the missive

The missive is routed toward the bank applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail or the technical mechanism linked to the SEPAmailmessagerie bancaire sécurisée. ecosystem involved.

Receipt of an acknowledgement missive

The SEPAmailmessagerie bancaire sécurisée. Participant is theoretically not obliged to perform any process when receiving the acknowledgement, except:

  • to get the statistics requested by the Schemele Scheme, ou Scheme SEPAmail, est l'entité au sein de laquelle les adhérents SEPAmail sont regroupés et qui a pour mission de maintenir la norme SEPAmail et les référentiels.
  • to comply with the requirements of the Participants charter

If it wishes to process these missives, it will have to implement the same procedure than the one used for the receipt of a nominal missive, with the difference that the acknowledgement missive is not itself acknowledged.

Modèle:Note: in case of errors within the acknowledgement missive during the checks (non compliant or non valid XML, non valid headers), these errors can therefore not be notified. The mechanism to resend the nominal missve or the escalation process must then be used in order to avoid the system to loop.

Check of the acknowledgement missive history

At this stage, it is possible to check whether the acknowledgement missive already has a history:

  • when receiving: do other acknowledgements exist on the same nominal missive ?
  • when sending: does a nominal missive exist ?

Internal routing of the missive to the IS

The missive is routed to the bank applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail or the technical mechanism linked to the SEPAmailmessagerie bancaire sécurisée. ecosystem if the logic of the bank IS requires it.

Sending a nominal missive

la séquence fonctionnelle autour de l'émission de missive

Recovery of the sending/information order

A nominal missive is sent after a sending order from a bank applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail.

The missive may be recovered as it is, in which case it is verified before signature/encryption and sending.

The missive may be created by the unattended machine.

In both cases, the following checks are performed.

Check of the BICBank Identifier Code, norme ISO 9362:1994

BICBank Identifier Code, norme ISO 9362:1994 are extracted from the inforamtion routed or deduced from a IBANInternational Bank Account Number, norme ISO 13616:2003@BICBank Identifier Code, norme ISO 9362:1994 referential. The two BICBank Identifier Code, norme ISO 9362:1994 must belong to a Participant@SCHEME or be SCHEME.

The one corresponding to the sender (FROM) must also be a BICBank Identifier Code, norme ISO 9362:1994 owned by the Participant.

Check of the ecosystem

The ecosystem may be deduced from the message included in the missive or transmitted by the bank applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail (preferred way). It must be an ecosystem managed by the SEPAmailmessagerie bancaire sécurisée. network, osned by ecosystem@SCHEME.

Check of MsvSnd

The field MsvSnd includes an identifier(IBANInternational Bank Account Number, norme ISO 13616:2003, QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code)., PANacronyme de Primary Account Number ou numéro de carte bancaire, ICQXidentifiant unique d'un créancier dans le réseau SEPAmail. Cet identifiant est géré par le SCHEME. Il est unique pour une entité économique et pérenne./BICBank Identifier Code, norme ISO 9362:1994, BICBank Identifier Code, norme ISO 9362:1994)

This identifier must correspond to a valid user of the SEPAmailmessagerie bancaire sécurisée. service.

It must therefore be active in one of the identifiers referentials managed by the Participant sending the missive: QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code).@BICBank Identifier Code, norme ISO 9362:1994, IBANInternational Bank Account Number, norme ISO 13616:2003@BICBank Identifier Code, norme ISO 9362:1994, PANacronyme de Primary Account Number ou numéro de carte bancaire@BICBank Identifier Code, norme ISO 9362:1994.

Check of the compliance of the XML of the message

The message to be enveloped in the missive is an XML document for which the compliance is checked.

Check of the validity of the XML message

The message is an XML document for which the following checks are performed:

  • it includes a reference to an XML schema of the family of the requested applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail,
  • it is valid.

Creation of the missive

A missive is created from the message and from previously checked information or, in the case of the initial routing of a missive, from an enrichment of this missive.

Time stamping

The missive is time stamped when sending, which means the XML content is enriched by filling in the "SndDtTm" field of the header of the missive with the date and time of the system.

Check of the compliance of the XML with the missive

The missive created at the previous step is an XML document for which the compliance is checked.

Check of the validity of the XML of the missive

The missive is an XML document for which the following checks are performed:

  • it includes a reference to the XML schema

sepamail_missive[6]

  • it is valid.

Calculation of the condensate of the missive

A condensate of the missive is calculated in accordance with a valid method declared in the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels characteristics (micalg attribute of the Content-Type header).

S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels signature of the sending Participant

The signature of the condensate previsouly created is performed with the private key of the sending SEPAmailmessagerie bancaire sécurisée. Participant, this key being dedicated to sending missives.

Encryption

The missive encryption is performed with the encryption public key of the receiver.

Creation of a MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels envelope

A MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels envelope is created. It includes:

  • the field FROM,
  • the field TO,
  • a first part including the missive, possibly encrypted,
  • a second part including the S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels signature of the missive.

Note: the possible attached documents of the message are attached to the message and therefore included in the XML as binary. The MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels mechanism of the attached documents is therefore not used for them but only for the missive AND for the signature.

Sending according to the priority

The priority of the missive is taken back for the routing.

Sending an ackowledgement missive

The case of an acknowledgement missive is similar. Only the message is replaced by the acknowledgement structure, including the acknowledgement code.

References

  1. http://xsd.sepamail.eu/current/sepamail_missive.xsd
  2. Permalien http://documentation.sepamail.eu/wiki/Lexique
  3. Guide des bonnes pratiques en matière de datation d’événements ou d'objets électroniques, http://www.fntc.org/, section guide (utilisateurs enregistrés)
  4. SMIRK escalade ESC1108
  5. Refer to the W3C definition here [1]
  6. http://xsd.sepamail.eu/current/sepamail_missive.xsd
Autres langues :English 99% • ‎Français 100%