Good day :-)
I am looking into using the Rebex MIME components (part of the Rebex IMAP/SSL pack) to implement AS2 communications. AS2 is a standard (RFC 4130) for business-to-business communication that consists of recommendations on the use of other pre-existing Internet standards. It uses HTTP or HTTPS (RFCs 2616, 2818) for delivery of messages and S/MIME (RFCs 2045, 2046, 3851) for the formatting of messages. Non-repudiation is achieved by Message Disposition Notifications, or MDNs (RFC 3798).
What's odd about AS2 is the way it merges these standards together. HTTP and MIME have a superficially similar structure: headers, blank line, body. When AS2 was being designed, from what I've understood, they decided that the S/MIME entity containing the content would actually be the HTTP body. A sample request in the RFC, for instance, looks like this:
POST /receive HTTP/1.0
Host: 10.234.160.12:80
User-Agent: AS2 Company Server
Date: Wed, 31 Jul 2002 13:34:50 GMT
From: mrAS2@example.com
AS2-Version: 1.1
AS2-From: "\" as2Name \""
AS2-To: 0123456780000
Subject: Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: mrAS2@example.com
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 2464
--as2BouNdary1as2
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
--as2BouNdary1as2
Content-Type: application/pkcs7-signature
[omitted binary pkcs7 signature data]
--as2BouNdary1as2--
You can see the HTTP headers ("Host", "User-Agent") mingling with MIME headers ("From", "Subject", "Message-Id").
My implementation platform is ASP.NET. ASP.NET parses out the HTTP request and headers before it hands off processing to an HTTP handler implementation. This makes the headers inaccessible to the MimeEntity's Load method, but that's easy enough to work around because, according to Microsoft's documentation, the Server Variable called "ALL_RAW" stores the raw text of the headers. I can prepend that to the POST data before passing it on to the MimeEntity's Load method.
Where I'm running into difficulties is at the opposite end of things. An AS2 request can ask that the recipient supply an MDN -- an electronic form of proving that you really did get the message -- and that MDN is also an S/MIME entity. It is merged similarly with the HTTP response:
HTTP/1.0 200 OK
AS2-From: 0123456780000
AS2-To: "\" as2Name \""
AS2-Version: 1.1
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Connection: Close
Content-Length: 1980
------=_Part_57_648441049.1028122454671
Content-Type: multipart/report;
Report-Type=disposition-notification;
boundary="----=_Part_56_1672293592.1028122454656"
------=_Part_56_1672293592.1028122454656
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
MDN for -
Message ID: <200207310834482A70BF63@\"~~foo~~\">
From: "\" as2Name \""
To: "0123456780000"
Received on: 2002-07-31 at 09:34:14 (EDT)
Status: processed
Comment: This is not a guarantee that the message has
been completely processed or &understood by the receiving
translator
------=_Part_56_1672293592.1028122454656
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit
Reporting-UA: AS2 Server
Original-Recipient: rfc822; 0123456780000
Final-Recipient: rfc822; 0123456780000
Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\">
Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1
Disposition: automatic-action/MDN-sent-automatically;
processed
------=_Part_56_1672293592.1028122454656--
------=_Part_57_648441049.1028122454671
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ
cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA
------=_Part_57_648441049.1028122454671--
This is where things get tricky. As with requests, in responses ASP.NET wants to handle the headers for you. The code I'm writing is only allowed to supply headers in name/value form, and the content must be independently written.
Looking over the Rebex MimeEntity class, I don't see an obvious way of doing an otherwise-normal serialization pass, but entirely omitting the headers and the blank line separating them from the body. Complicating matters is the obfuscation that I understand you've needed to apply in the wake of the "ComponentForge" nastiness -- ordinarily, I'd be able quickly to tell in a general sense whether it is possible with existing code, but the obfuscation slows things down enough that it is a better use of my time simply to ask. :-)
At this point in time, I am considering work-arounds such as serializing the MimeEntity to a buffer, scanning for the blank line, and then emitting only those bytes that come thereafter. Obviously, though, this is inelegant and inefficient, and if there is a way to achieve my goal more directly (which, in this case, means emitting the serialized parts of a multipart message, boundaries and all, but omitting the headers), it would be greatly preferable to do it that way.
So, can it be done? :-)