ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

MDN

Message Disposition Notification. L'accusé MIME que le destinataire retourne pour confirmer qu'il a reçu et traité le message — la preuve de bonne fin en AS1/AS2/AS3.

Définition

Le MDN est défini par la RFC 3798 (mai 2004) et la RFC 8098 (rev. février 2017). Son format est multipart/report; report-type=disposition-notification avec trois parties :

  • Une partie texte (text/plain) lisible par un humain.
  • Une partie machine (message/disposition-notification) avec champs structurés : Reporting-UA, Original-Recipient, Final-Recipient, Original-Message-ID, Disposition (action automatique + manuelle + processed/displayed/dispatched/deleted/error), Received-Content-MIC (en AS2, le MIC SHA-256 ou SHA-1 du message reçu).
  • Une partie message (message/rfc822) qui renvoie tout ou partie du message d'origine — optionnelle.

Quand le MDN est signé (S/MIME PKCS #7), il devient pour les EDIINT la preuve de non-répudiation de réception (NRR) : en signant un MIC du message reçu, le destinataire atteste qu'il a bien le document et qu'il n'en peut nier la réception ultérieurement. C'est cette propriété qui distingue AS2 d'un simple POST HTTPS.

Origine

Le concept de MDN sort de la RFC 2298 (1998), reprise et stabilisée par la RFC 3798 (2004) et la RFC 8098 (2017). Initialement destiné aux clients de messagerie pour les accusés de réception et de lecture, le MDN est adopté par EDIINT (RFC 3335 AS1, RFC 4130 AS2, RFC 4823 AS3) comme l'accusé standard. Le MDN signé est cité comme l'innovation EDIINT clé qui apporte non-répudiation à l'EDI sur internet.

Exemple en contexte

Disposition-notification d'un MDN AS2 réussi :

Lecture : traitement automatique réussi (processed), MIC SHA-256 du contenu reçu. Le MDN est signé S/MIME ; l'archive {`message envoyé, MDN signé`} suffit à prouver la transmission.

Termes liés

Dernière mise à jour: 14 mai 2026