receiving filename from other AS2 server
amir,
I just made a test to verify this and it seems to work:
[9:46:34 AM] mendAS2-1216107994613-341@mendelsontestAS2_mycompanyAS2: MDN created, state set to [processed].
[9:46:34 AM] mendAS2-1216107994613-341@mendelsontestAS2_mycompanyAS2: Synchronous MDN sent as answer to message mendAS2-1216108011281-0@mycompanyAS2_mendelsontestAS2.
[9:46:34 AM] mendAS2-1216108011281-0@mycompanyAS2_mendelsontestAS2: AS2 communication successful, payload 1 has been moved to "/as2/messages/mendelsontest/inbox/mycompany/testmessage.txt".
I sent a file with the name "testmessage.txt" here and the remote server wrote the data into a file of the same name. To enable it you have to go to the partner panel and enable the option "Receipt-Keep original filename on receipt".
But you are right, it is not ensured that this works because transfering the original filename is not part of the AS2 standard. There has to be a header like the following in the attachment part that contains the filename:
Content-Disposition: attachment; filename=testmessage.txt
This is parsed by our as2 solution. It would be great if you could send me the message your TP sent you, I will have a look into it to see where the filename is stored (please send me an unencrypted as2 message).
sh at mendelson dot de
Regards
Heller
edit:
wait a second, just had a look and the file IS still in _rawincoming (didn't expect that!) :-)
Sending you the file(s).
----------original post.
unfortunately I don't have this anymore. The reason is that the message was successfully verfied and mec-as2 server has extracted payload. There is no file stuck in _rawincoming as there was no error :-)
I do see the headers in the client app and I also see the "Raw data (unencrypted)" tab in app and in there I see the data but I think this is stored in the database (not on the file system). Is there a way to extract from the DB in a format you can check? (assuming the entire raw message is in the database).
not sure if you mean ignore the entire post, but retaining original file name works, storing in separate folders inside inbox (based on partner) works. I've attached a sample log below for filename retention:
Message id: mec_as2-1215920527870-0@UL020AS2_TLXAS2
Sender host: X.X.X.217
Sender system: m-e-c as2 1.0 build 23 - www.mendelson-e-c.com
Original filename: R163244.EXE
MDN: SYNC
Signature: Unknown
Encryption: 3DES
--------------------------------------------------------------------------------
Log:
[7/12/08 11:43:07 PM]
mec_as2-1215920527870-0@UL020AS2_TLXAS2: Incoming transmission is a AS2 message,
raw message size: 6.51 MB.
[7/12/08 11:43:07 PM]
mec_as2-1215920527870-0@UL020AS2_TLXAS2: AS2 message is encrypted.
[7/12/08 11:43:13 PM]
mec_as2-1215920527870-0@UL020AS2_TLXAS2: The data has been decrypted using the
key "tlxas2".
[7/12/08 11:43:14 PM]
mec_as2-1215920527870-0@UL020AS2_TLXAS2: AS2 message is signed.
[7/12/08 11:43:15 PM]
mec_as2-1215920527870-0@UL020AS2_TLXAS2: The sender used the algorithm SHA1
to sign the message.
[7/12/08 11:43:15 PM]
mec_as2-1215920527870-0@UL020AS2_TLXAS2: Using certificate "ul020" to verify
signature.
[7/12/08 11:43:15 PM]
mec_as2-1215920527870-0@UL020AS2_TLXAS2: Digital signature verified successful.
[7/12/08 11:43:24 PM]
mec_as2-1215920604006-15@TLXAS2_UL020AS2: Outgoing MDN has been signed with
the algorithm "SHA1".
[7/12/08 11:43:24 PM]
mec_as2-1215920604006-15@TLXAS2_UL020AS2: MDN created, state set to [processed].
[7/12/08 11:43:24 PM]
mec_as2-1215920604006-15@TLXAS2_UL020AS2: Synchronous MDN sent as answer to
message mec_as2-1215920527870-0@UL020AS2_TLXAS2.
[7/12/08 11:43:24 PM]
mec_as2-1215920527870-0@UL020AS2_TLXAS2: AS2 communication successful, payload
1 has been moved to "/mnt/EDI/../inbox/R163244.EXE".
@totalogistix
Thanks for the post, having talked to Heller its clear its a non-standard extension to AS2 which is why it works for you (mecas2 to mecas2). I'm interfacing with WebMethods and that's not utilizing the same extensions.
Its clear it wont work for me, but its no show stopper. Thanks for posting anyhow :-)
This sounds exactly what I'm running into.
Partner is expecting to see the send filename appear in the "Content-Disposition" header. I've got the filename appearing in the "Subject" header.
I found on the Send tab, "Payload subject:" which I set to ${filename} and that gets the filename into the "Subject" header.
Can we choose to have the filename appear in the "Content-Disposition" header instead?
This is what they would like to see if I called my file HELLO.TXT
Content-Disposition: attachment; filename=HELLO.TXT
--Russ
I see a filename in the content-disposition header, but it does not match the filename I sent.
The filename I sent was AGPTMT00.011 which appears in the subject line. The content-disposition header has a filename as well, but it always says filename="smime.p7m"
Here are the headers from one test I did:
recipient-address = https://servicegate.mtsallstream.com:59443/bcgreceiver/AS2receiver
message-id =
AS2-Version = 1.1
as2-to = MTS
subject = filename=AGPTMT00.011
disposition-notification-to = https://as2.provtel.com:8443/mec_as2/HttpReceiver
as2-from = ProvTel
connection = close, TE
content-disposition = attachment; filename="smime.p7m"
Content-Type = application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m
disposition-notification-options = signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha1,
md5
Expect = 100-continue
User-Agent = m-e-c as2 1.0 build 23 - www.mendelson-e-c.com
from = as2@provtel.com
mime-version = 1.0
Content-Length = 3546
Host = servicegate.mtsallstream.com:59443
date = Mon, 29 Sep 2008 13:21:07 CDT
rdo911,
the AS2 message is sent in multipart MIME format if it is signed. Each part has its own headers. The header you mentioned is the message header.
The content part has by default the content type "application/EDI-Consent" and looks like the following sample:
------=_Part_1_16179550.1222766030296
Content-Type: application/EDI-Consent
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=edifact.orders.test
UNA:+.? 'UNB+UNOB:2+sender:ZZZ+receiver:ZZZ+981103:1400+124'U..
If your communication is not already in productive state: Please use m-e-c as2 b25 instead of b23, there are a lot of issues fixed in the new version.
Regards
Heller
Yes, you are correct. I sent you the wrong headers. This is one transaction that I received from our partner. Found it in the _rawincoming directory.
------=_Part_3_400146140.1221711732988
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="AGALC100.126"
This is a test 1
This is a test 2
This is a test 3
This is a test 4
This is a test 5
------=_Part_3_400146140.1221711732988
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: binary
They are expecting us to put our filename just like they put AGALC100.126 as their filename.
PS....Thanks for the tip. I have downloaded b25. Will switch everything over to that version shortly.
I've got b25 going now.
I tried to send my file AGPTMT00.008 but the filename is not appearing in the headers.
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----=_Part_2_13810515.122270
9690746"
------=_Part_2_13810515.1222709690746
Content-Type: application/pkcs7-mime; name="smime.p7z"; smime-type=compressed-data
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7z"
Content-Description: S/MIME Compressed Message
My partner is happy with all of the above except this line:
Content-Disposition: attachment; filename="smime.p7z"
I need to send it to them as
Content-Disposition: attachment; filename="AGPTMT00.008"
rdo911,
please have a look at RFC 3851. A good choice for the filename in the header parameter of a compressed part seems to be "smime.p7z" (as it is realized in m-e-c as2):
3.2.1. The name and filename Parameters
For the application/pkcs7-mime, sending agents SHOULD emit the optional "name" parameter to the Content-Type field for compatibility with older systems. Sending agents SHOULD also emit the optional Content-Disposition field [CONTDISP] with the "filename" parameter.
If a sending agent emits the above parameters, the value of the parameters SHOULD be a file name with the appropriate extension:
MIME Type File Extension
application/pkcs7-mime (SignedData, EnvelopedData) .p7m
application/pkcs7-mime (degenerate SignedData .p7c
certificate management message)
application/pkcs7-mime (CompressedData) .p7z
application/pkcs7-signature (SignedData) .p7s
In addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name; the use of the filename base "smime" SHOULD be used to indicate that the MIME entity is associated with S/MIME.
© 1999-2008 mendelson-e-commerce GmbH. All right reserved.
Hi,
I was wondering if anyone has managed to store the filename from a remote client sent to MEC-AS2 server?. My trading parter has turned on everything he can and I've said store the filename in the partner configuration but its not happening.
I was wondering if this is a feature anyone has had sucesss with ?