Filename header decoding issue about openas2app HOT 6 CLOSED

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.

from openas2app.

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.

from openas2app.

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.

from openas2app.

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!

from openas2app.

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 :)

from openas2app.

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.

from openas2app.