AS2 Messages & Receipts

Files.com supports AS2 for exchanges with trading partners that require it. AS2, Applicability Statement 2, is a protocol for sending business messages over HTTP or HTTPS, with agreed message identities, encryption, signatures, and receipts.

With AS2, businesses can exchange messages directly over the internet instead of sending through a value-added network or another intermediary. If the intermediary also supplies partner connectivity, mapping, or record validation, moving to a direct connection means accounting for those services separately.

Our Recommendation

At Files.com, we recommend against choosing AS2 for a new exchange because its setup effort and ongoing coordination are disproportionate to the added protection for most B2B transfers. Files.com's API over HTTPS and SFTP already provide strong encryption in transit. Together with appropriate authentication and permissions, that is enough for routine business files.

Message encryption, signatures, and signed receipts do serve useful purposes, but both businesses must coordinate the certificates, renewals, settings, and receipt validation that make them work. A certificate mismatch or incompatible message profile can stop an otherwise straightforward delivery. For most routine exchanges, we believe the extra work and risk of interrupted deliveries outweigh the incremental protection.

Requiring those layers simply because a file contains business records can become security theater: a great deal of ceremony with little improvement in the outcome that matters. A routine order for nonsensitive manufactured parts has different needs from confidential, time-critical trading records whose disclosure could cause immediate financial loss. Choose protection according to the data and its consequences.

We support AS2 so you can meet existing trading partners' requirements and move away from legacy MFT systems without disrupting those relationships. If a partner requires it, use AS2 and agree on the message and receipt profile. When the choice is yours, follow our connection recommendations.

Messages and Identities

An AS2 transmission packages a payload with message information and identifies the sending and receiving AS2 systems. The partners agree on each system's AS2 identity, endpoint URL, public message certificate, encryption and signing choices, and receipt requirements.

An AS2 identity names a system in the agreed configuration; it is not a password. The receiver checks the sender's use of the agreed signing key through the message signature, while message encryption limits reading to a system holding the recipient's private key. If the connection uses HTTPS, its certificate separately identifies the network endpoint.

AS2 can carry EDI, CSV, JSON, XML, or another agreed payload. The transport delivers the message; it does not decide what a purchase order means or map fields into an accounting system. Data Exchange Formats explains the data agreement and how TransformScript and Automations v2 process those records on Files.com.

Message Disposition Notifications

The receiving AS2 system reports its processing outcome in a Message Disposition Notification (MDN). A successful MDN indicates acceptance at the AS2 layer under the agreed profile, while a failure MDN can explain what went wrong. Because either outcome can have a signed receipt, the sender needs to check the reported disposition as well as the signature.

The sender verifies a signed MDN using the receiver's public message certificate and compares its Message Integrity Check (MIC) with the value calculated for the sent message. That comparison ties the receipt to the received content under AS2's processing rules. Those rules determine which bytes are checked, so the MIC can differ from a checksum of the original unwrapped file.

An HTTP success response tells you that the HTTP request was handled. To find out whether the AS2 system accepted the message, inspect the MDN's disposition, any required signature, the matching message identity, and the MIC together. A successful HTTP response can carry an MDN reporting a failed AS2 result.

Evidence of Receipt

Non-repudiation of receipt is the business concept of retaining evidence that a particular partner received particular content. A correctly validated signed MDN, correlated with the sent message and matching MIC, supplies cryptographic evidence for that purpose. The complete signing and receipt profile determines the evidence available.

Keep the sent message's identifying information, the receipt, validation results, and the certificate information needed to interpret them. A transfer status without the underlying evidence may be insufficient for a later reconciliation. AS2's standardized receipt model supports this record; the business agreement determines its use and retention requirements.

The evidence concerns receipt by the AS2 system. An invoice or order can still fail validation or import afterward, so business acceptance needs an acknowledgment from the relevant EDI or application process. An MDN cannot supply that later result.

Synchronous and Asynchronous Receipts

With a synchronous MDN, the sender waits for the AS2 result on the same HTTP connection that carried the message. If the response is lost, the sender can be left uncertain even though the receiver accepted the message.

An asynchronous MDN returns later in a separate HTTP(S) request to the sender's receipt URL. This requires a reachable endpoint at the sender and a permitted connection from the receiver. The sender needs to correlate that later MDN with the original message and apply a timeout so a missing receipt becomes visible; the original HTTP response alone does not complete the exchange.

The choice concerns how the receipt travels, not whether a receipt is signed or whether it reports success. Both arrangements need the agreed receipt validation. Document the callback URL and firewall path separately when asynchronous delivery is required.

Compression

AS2 message compression reduces the size of the packaged content using an agreed compression representation. It is a separate operation from encryption and signing, and is different from placing a .zip file inside the payload. Both AS2 systems must support the selected profile and its ordering of compression and signing.

Compression can help with EDI text but adds little for a payload that is already compressed. A representative message test lets you check that the other system can unpack the chosen profile, since settings named “compression enabled” need not mean the same thing on both sides. RFC 5402 describes compression within AS messages.

Files.com AS2 Exchanges

Files.com AS2 configuration connects identities, trading partners, certificates, and exchange folders. It automatically decompresses compressed incoming AS2 transmissions. For incoming messages, Files.com returns MDNs synchronously; agree on that receipt mode with the sender rather than assuming every AS2 receipt arrangement is supported.

Transmissions and Receipts explains the available records, MICs, processing results, and message retention. Certificates and Encryption explains message-certificate trust and renewal. Use those settings and limits to configure Files.com after the two businesses have agreed on the exchange profile.