Message Disposition Notification
The Message Disposition Notification ( MDN ) is an acknowledgment of receipt of an electronic message to its sender via the Internet. The MDN thus represents the Internet version of the well-known “registered mail with acknowledgment of receipt” for letter post. The MDN always comes back via the same transmission path as the message to be confirmed. The MDN of the Request for Comments (RFC) is standardized on the Internet transmission paths e-mail , HTTP and FTP . An undeniable MDN from the recipient and at the same time secure data exchange are standardized by the RFC as AS1 (for e-mail), AS2 (for HTTP) and AS3 (for FTP).
A distinction is to be made between the MDN and the Delivery Status Notification (DSN, 'transmission status message'), which, as an automatically generated server message, is similar to a notification of the successful delivery of a registered letter.
Insecure MDN using the example of an e-mail program
In the case of e-mails, one usually speaks of read receipts , although technically an insecure MDN is used here. The sender can configure his mail program so that the recipient of the mail should confirm receipt. However, the recipient can set his mail program so that a confirmation is never sent back (i.e. it is ignored), or that he is asked every time whether a read receipt should be sent.
Secure MDN
General
On the other hand, one speaks of a secure MDN if three conditions are met:
- A so-called adapter runs on the receiving end and always automatically sends back an MDN before the message has been passed on to the reader.
- The MDN is provided with a signature that proves that the MDN was actually issued by the recipient and that it was not returned to the sender as a manipulated message by a third party.
- The MDN also contains a hash value for the received message, so that recipients and senders can also check for themselves which message was used to issue an MDN.
The secure MDN is standardized as AS1 (for e-mail), AS2 (for HTTP) and AS3 (for FTP), which essentially describe the so-called AS1 adapter, AS2 adapter or AS3 adapter in terms of its behavior and requirements.
Example: pharmacovigilance
The drug safety departments of pharmaceutical companies are obliged to electronically report side effects and so-called SUSAR to the relevant authorities, for example the BfArM , the European Medicines Agency or the FDA , within a certain period of time . Both the authority and the pharmaceutical company use a so-called ESTRI gateway for this purpose . If the pharmacovigilance department receives a reportable case, this is first entered in its registration system. From there the case is sent to the ESTRI gateway. This system encrypts the case and sends it to the agency using either the AS1 or AS2 standard. The agency then sends an MDN back to the pharmaceutical company. After the successful import into the authority database, a confirmation (acknowledgment) is sent by the authority to the pharmaceutical company. The pharmaceutical company in turn confirms receipt of the confirmation by means of an MDN. The confirmation is then imported into the pharmaceutical company's database. If this is successful, the authority receives a confirmation, which in turn confirms this with an MDN. The complete process is described in the guidelines EMA / H / 20665/04 / Final Rev. 2 .
Norms and standards
- RFC 8098 (MDN for e-mail with POP3 retrieval): The introduction to X.400 also describes the history here .
- RFC 3503 (MDN for email with IMAP retrieval)
- RFC 4823 (MDN for FTP)
Individual evidence
- ↑ KDE Kolab user manual Message Disposition Notification ( Memento from January 28, 2006 in the Internet Archive )
- ↑ Note for guidance - EudraVigilance Human - Processing of safety messages and individual case safety reports (ICSRs) (PDF; 860 kB)