Messages sent twice
This page explains what MicroB2B does when a partner sends the same message again, or a file name it sent before.
Why messages arrive twice
A partner sends a message again when it did not get your receipt, for example because the connection broke. Someone who captured a message could also try to send it again. MicroB2B accepts each message once, so your systems never process the same document twice by accident.
How MicroB2B recognizes a repeat
Every AS2 message has a Message-ID header.
MicroB2B accepts each Message-ID once per partner.
It checks this only after it has verified the signature.
So a message that does not authenticate cannot take the Message-ID of the partner’s real message.
What happens to a repeat
Same content. The message is not passed on again.
The partner gets the same receipt the first message got, unchanged.
If no receipt was kept for the first message, the partner gets a new one, processed/warning: duplicate-document.
Different content. The Message-ID was reused for another document.
The message is refused with processed/error: integrity-check-failed and not passed on.
Ask the partner to use a new Message-ID for every message.
The first message is still in progress. The partner gets processed/error: unexpected-processing-error.
Without a receipt request, it gets HTTP 500.
The partner’s next resend gets the real answer.
The rules for asynchronous receipts apply to a repeat as to any message. See Receipts you send.
Replayed signatures
The Message-ID is not covered by the signature.
So someone could post a captured signed message again under a new Message-ID.
MicroB2B also accepts each signature only once per partner.
A replay is refused with processed/error: authentication-failed (HTTP 400 without a receipt request) and not passed on.
Changing the encoding or the certificates in a captured signature does not make it new.
A partner that sends a document again under a new Message-ID signs it again.
The new signing time makes it a new signature, so this is not a replay.
Only a document signed twice in the same second, under two Message-IDs, would look like one.
Unsigned messages carry no signature and are not checked this way.
For a partner that does not have to sign, whoever sends a Message-ID first holds it.
Require Incoming Signatures on the partner profile closes that gap.
What you see
The repeat is kept as a message of its own, with the status Refused.
It names the message it repeated.
The first message’s history gets a Duplicate received line.
MicroB2B logs a warning.
A message that was never passed on, for example because of a storage error, gives back its Message-ID and its signature.
The partner’s resend is then accepted.
If MicroB2B stopped while it handled a message, a resend with the same Message-ID takes over after 10 minutes.
Repeated file names
Some partners want to hear when they send a file name they sent before. This comes from banking, where a repeated file name can mean a payment file sent twice. MicroB2B then does not pass the repeat on, and its receipt says why.
Choose the behavior per partner, in the Message options section of the partner’s AS2 profile:
| Repeated File Names | What happens |
|---|---|
| Accept (do not check file names) | File names are not checked. This is the default. |
| Accept with a warning in the MDN | The message is passed on. Its receipt says processed/warning: duplicate-filename. |
| Refuse with an error in the MDN | The message is not passed on. It ends Refused with the file name and the earlier message. Its receipt says processed/error: duplicate-filename. Without a receipt request, the partner gets HTTP 400. |
Repeated File Name Window (hours) sets how long a name counts as received. The default is 24 hours, counted from the latest accepted message with that name.
Some details:
- Names are compared exactly.
Order.xmlis notorder.xml. - A refused message does not count, whatever the reason. The partner can send it again.
- A message that was only warned about was passed on, so it does count.
- A message without a file name is never checked.
- A resend with the same
Message-IDis treated as a repeat of that message, not as a repeated file name. - Two messages with the same name that arrive at the same moment may both be accepted.
Recommended: leave this at Accept unless a partner asks for it. Partners that ask usually refer to Drummond’s “Filename Preservation with MDN” (FN-MDN) profile.