Christopher Broderick

Although there is a log message saying: 2024-03-19 12:32:27.754 FINER MDNSenderModule: ASYNC MDN send started... This is not actually correct - that is emmitted at the start of the MDN sender module and it has not yet checked if it should send ASYNC or SYNC yet. It looks for a header named "Receipt-Delivery-Option" and if present it will send asynchronously but there is none in the received message and subsequently sends a SYNC MDN as it should. (I will change the misleading debug message in a next...

Although there is a log message saying: 2024-03-19 12:32:27.754 FINER MDNSenderModule: ASYNC MDN send started... This is not actually correct - that is emmitted at the start of the MDN sender module and it has not yet checked if it should send ASYNC or SYNC yet. It looks for a header named "Receipt-Delivery-Option" and if present it will send asynchronously but there is none in the received message and subsequently sends a SYNC MDN as it should. (I will change the misleading debug message in a next...

The sender chooses SYNC or ADYNC MDN and the receiver automatically responds in the selected mode. You do not need to do anything. I will take a closer look at what could be triggering the error on their end in a couple days.

The software makes a best effort to extract the file. However, the built-in security within the AS2 protocol means that you can only extract the file once you have properly identified the sender, matched it to their publ;ic key to verify the signature then used the private key linked to that specific partner to decrypt the file. So OpenAS2 provides extensive logging telling you what went wrong and why. If you feel there are scenarios that could be helped by better logging, let me know and I will...

If you control grenerating the filename then try using a a $, @, & or % for the separator and that should cater for AS2 ID's that use either dash or underscore:] delimiters="$" Then filenames like this would work with the default tokens used in the "format" attribute: My_AS2ID$THEIR-AS2ID$TestFile.txt Alternatively, change the order of the tokens in the default attribute to this:\ format="attributes.filename",sender.as2_id, receiver.as2_id" Then the receiver AS2 ID can contain any number of dashes...

Thanks for the detailed troubleshooting info you did - made it easy to identify where the problem was. Version 3.9.1 just released fixes that issue.

The AS2 specification is very clear on utilisation of the MIC: https://datatracker.ietf.org/doc/html/rfc4130 Specifically, the receiving party (in this case it is your partner receiv ing your message) must calculate and return the MIC to the sender. The sender does NOT send the MIC and there is no indication of requirement to do this in the sAS2 tandard as linked to above. Note that the sender does tell the receiver whether they are expecting a signed receipt and in OpenAS2 you do that using this...

Quite often this sort of issue turns out to be a mistake on the partner side and they sent you a pub;lic key that is not matched to the private lkey they configured into the partnership on theoir side.