Receipts you send
When a partner asks for a receipt (MDN), MicroB2B sends one. This page explains when and how it does that, and what the receipt says. For the receipts you ask your partners for, see Receipts (MDNs).
When a partner asks for a receipt
The AS2 receiver sends the receipt. It is signed if the partner asked for a signed one. MicroB2B signs with the partner profile’s Our Certificate, or else the organization’s.
For an asynchronous request, the receiver answers with an empty 200 OK at once.
Then it sends the receipt to the URL the partner named.
If that fails, it retries as set on the receiver.
Which URLs are allowed. The partner chooses the receipt URL, so MicroB2B limits it.
The host must be the host of the partner’s Endpoint, or one of its Receipt Delivery Hosts.
The URL must be http or https without a user name or password.
A message that asks for another URL is refused with HTTP 400 before anything is stored.
When an asynchronous receipt is sent. Only an authenticated message gets one by default:
- A signed message whose signature verifies always gets it.
- A message whose signature fails, or that is unsigned although the partner must sign, gets it only with Send Receipts for Signature Failures.
- Any other unsigned message gets it only with Send Receipts for Unsigned Messages.
Both options are off by default. Neither one lifts the URL rule.
A message without an asynchronous receipt gets its answer in the HTTP response only.
That is 200, or an error status when it was not processed, with a warning in the log.
The same happens to a message refused before it was read, such as one over the size limit.
What your receipts say
The Disposition line of a receipt tells the partner what happened.
Your logs and the message history give a more specific reason than the partner sees.
| Disposition | When |
|---|---|
processed | The message was accepted. |
processed/warning: duplicate-document | A repeat of an accepted message, when no receipt was kept for the first one. See Messages sent twice. |
processed/warning: duplicate-filename | A repeated file name, accepted with a warning. |
processed/error: authentication-failed | The signature does not verify, there is no certificate to check it, the sender is unknown, or the signature was received before under another Message-ID. |
processed/error: decryption-failed | None of your certificates can decrypt the message. |
processed/error: decompression-failed | The compressed content cannot be unpacked. |
processed/error: insufficient-message-security | The profile requires a signature or encryption the message lacks. |
processed/error: integrity-check-failed | The Message-ID was used before for a different message. |
processed/error: duplicate-filename | A repeated file name, refused. |
processed/error: unexpected-processing-error | Anything else: an unknown organization, a message over the size limit, content that cannot be read, a repeat of a message still in progress, or a failure on your side. |
failed/failure: sender-equals-receiver | AS2-From and AS2-To are the same. |
failed/failure: unsupported format | The partner requires a signed receipt in a format other than pkcs7-signature. |
failed/failure: unsupported MIC-algorithms | The partner requires checksum algorithms that are not supported. |
The three failed/failure cases are refused before the message is read.
Nothing is stored, and a receipt is only sent when a synchronous one was requested.
Every receipt names MicroB2B in its Reporting-UA field, with your AS2 ID.
Hide the version under System > Settings > Identification leaves out the version.