Filename header decoding issue

[pbyzkn]

Hello.

I've encountered an issue while using OpenAS2 in my environment, I use OpenAS2 to receive files, and it can happen that the file will come with a non-ASCII character in its name. Currently my partnerships.xml file has the following line for a partner definition:

<attribute name="store_received_file_to" value="/mnt/Company/Inbound/Invoices/$msg.content-disposition.filename$"/>

While this works fine for majority of files, when files have non-ASCII characters the Content-Disposition attribute from header can take an RFC2047 form (such as attachment; filename="=?UTF-8?Q?20240605=5F176=5FFaktura=5F0003=5F05=5F2?= =?UTF-8?Q?4=5FPOLAND=5FSP=C3=93=C5=81KA=5FZ=5FOGR=2Epdf?=") which results in file being saved under name that is still encoded according to that RFC (with exception of it not having illegal characters).

My question is, does OpenAS2 have any built in method of decoding received filenames that I could possibly use in configuration? Or am I missing something obvious? I tried searching discussions both on GItHub as well as SourceForge, reading docs, however to my surprise I haven't found any other user experiencing similar issue nor any solution specified in the documentation. I figured that there is only one reference to Java function that handles decoding of this sort in https://github.com/OpenAS2/OpenAs2App/blob/94153f2383fe8f9e93f69549c17e3285b51460bd/Server/src/main/java/org/openas2/processor/receiver/AS2ReceiverHandler.java#L630 however this does not seem to concern in any way received files and only sent MDNs.

Thank you for your time and building a great program!

[uhurusurfa]

I have run a couple of tests and the only way that I can produce your problem is if I pre-encode the filename in BASE64. It appears that your partner is pre-encoding the filename which then gets encoded again in BASE64 by the Mime handlers of your partner software and when decoded in OpenAS2 (decoding headers per RCC2047 is built into the Mime handlers in the Java library used by OpenAS2) it produces the string sequences you see. The only fix is to add a configurable option in per partner to trigger a re-parse of the ddecoded filename checking for RFC2047 character sequences and decode the string again otherwise this adds an unnecessary overhead for 99.999% of users of OpenAS2.

Before I commit to adding this optional feature, please check if your partner can prevent the pre-encoding of the filename.

[uhurusurfa]

Note that if you decode the fielname string you provided it comes out as this: 20240605_176_Faktura_0003_05_24_POLAND_SPÓŁKA_Z_OGR.pdf

I am guessing that somwhere in their EDI pipeline they think it best to BASE64 encode the filename if it contains non-ASCII characters and do not decode it before pushing it into their AS2 handler.

[pbyzkn]

First off, thank you so much for looking into that. I really appreciate you taking your time to check on this!

As to the problem at hand, I see. The rest of the message header (saved in data/msgheaders) looks fine, it looks like this (redacted a few things that aren't relevant and could be considered private):

Headers:
Content-Type: application/octet-stream;
        name="=?UTF-8?Q?20240605=5F93=5FCredit=C2=A0Note=C2=A0=282=29=2Epdf?="
Date: Wed, 05 Jun 2024 13:12:54 GMT
From: <email>
Message-Id: <1717593174807.16767981@mkwFm41ibDzbfJ1c>
MIME-Version: 1.0
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="=?UTF-8?Q?20240605=5F93=5FCredit=C2=A0Note=C2=A0=282=29=2Epdf?="
Disposition-Notification-To: <email>
Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha-256
Receipt-Delivery-Option: <URL>
EDIINT-Features: CEM, multiple-attachments, AS2-Reliability
AS2-Version: 1.2
AS2-To: <recipient>
AS2-From: <sender>
Content-Length: 61140
User-Agent: Axway-Interchange/26.5.0 build-c31dd875
Host: <IP address>
Connection: close

Attributes:
HTTP_REQUEST_TYPE: POST
destination_ip: /10.0.0.5
destination_port: 4080
HTTP_REQUEST_URL: /as2/incoming/
source_port: 26434
source_ip: /<IP Address>

Partner's AS2 program seems to be Axway-Interchange in case this is relevant for someone else dealing with this issue in the future. I'll now ask partner to look into that on their side if they have an option to control encoding of filename. I'll let you know when I know more!

[uhurusurfa]

There are a number of users who have interfaced to Axway successfully and this issue has never cropped up so I am certain it is something specific to your EDI partners pipeline that feeds the file to their Axway system.

[pbyzkn]

I'll assume this issue really lies with partner's pipeline. They are unfortunately unwilling to change, but since this isn't an issue with OpenAS2 implementation I do not want to burden OpenAS2 developer team with adding additional mitigations for partner's specific configuration, we will likely go back to previous used AS2 solution which for some reason worked. Thank you so much for giving me this useful information. I wish you a great day :)

[uhurusurfa]

Ok - sounds like it is worth adding to OpenAS2 if the double decoding is supported by your other app indicating that this may be a more general issue for EDI pipelines.