EFT Server incorporates a Drummond-certified AS2 adapter to support inbound and outbound AS2 transfers. Drummond certified means that EFT Server's AS2 module has achieved interoperability with other Drummond-certified AS2 servers and clients. (The AS2 component used in EFT Server is /n software's IP*Works EDI v8.3 Engine, in compliance with RFC4130.)
If you are transferring files using HTTP, the payload must be encrypted; if the payload is not encrypted, HTTPS must be used. This rule applies to both inbound and outbound transactions. Encrypting the payload and sending it over HTTPS provides additional protection from "man-in-the-middle" attacks.
EFT Server supports inbound Multiple Attachments (MA) for processing a single message with multiple payloads. MA messages are treated the same as normal messages with the exception that multiple files are processed.
What EFT Server's AS2 module does not do
EFT Server does not support, non-encrypted payloads over plaintext HTTP, asynchronous (A receipt returned to the sender on a different communication session than the sender's original message session.) MDN (Message Disposition Notification; The Internet messaging format used to convey a receipt. This term is used interchangeably with receipt. An MDN is a receipt.) deliveries via SMTP for outbound transactions (but does support inbound ones), EDI file content manipulation (translation, extraction, transformation, loading), or outbound Multiple Attachments (MA). EFT Server does not determine if the data sent or received is usable; it only transfers the data. The AS2 module is "push only"; that is, EFT Server does not request files.
How EFT Server manages AS2 transmissions
In receiver mode (inbound), EFT Server examines the header, then determines whether to process it as a normal file transfer, as an MDN, or as an AS2 transmission. If the file is an AS2 transmission, EFT Server sends a receipt and an HTTP response.
An On File Upload event occurs for each file uploaded in an MA transaction.
An AS2 Inbound Transaction Succeeded event occurs just once per transaction after all files are received and the MDN (if requested) is successfully sent.
An AS2 Inbound Transaction Failed event occurs if an AS2 file upload failed for any reason, such as bad MIC, no permissions/access, duplicate message ID, or other AS2 transfer-related error.
In sender mode (outbound), EFT Server provides granular control over AS2 configuration, such as synchronous versus asynchronous receipts.
Outbound AS2 with synchronous MDN - EFT Server waits for the MDN to be returned before completing the transaction.
Outbound AS2 with asynchronous MDN - EFT Server does not wait for the MDN to be returned, but tells the remote server where to send the MDN.
EFT Server determines once every 60 minutes whether an asynchronous MDN is received. The transaction status is considered a failure if the MDN is not received within a specified duration. The default duration is 7200 minutes (5 days), but you can change this setting on the AS2 Outbound tab, in the Asynchronous receipt timeout box.
An AS2 Outbound Transaction Succeeded event occurs after EFT Server has successfully offloaded a file to a remote partner and, if a receipt was requested, a valid receipt was received that indicates the transfer was successfully completed.
An AS2 Outbound Transaction Failed event occurs if EFT Server has failed to offload a file to a remote partner, an MDN receipt sent by EFT Server was not received in the specified duration, or the receipt signature or MIC failed.
EFT Server sends e-mails and executes commands only after the final transaction status (Failure or Success) is known. The success or failure to receive the MDN is stored in the database and can be viewed in reports and AS2 Transactions node.
How EFT Server determines failed AS2 transmissions
AS2 transfers may have more than a simple success or failure outcome. For example, an outbound AS2 file transfer may succeed, but no MDN received from the remote host. This could be considered an outright failure in some cases. Another example of a failure is when a file is successfully sent, but the received MDN’s signature cannot be verified. Not all AS2 systems consider these partial failures an overall failure. For example, a remote host may accept an inbound file even though its signature was bad or had other issues, yet still accept the file.
EFT Server accepts most AS2 transmissions, even if there is a MIC (The message integrity check (MIC), also called the message digest, is the digest output of the hash algorithm used by the digital signature. The digital signature is computed over the MIC.) mismatch or the signature used to sign the payload was not found. However, the overall transaction is not considered a success unless every part of the transmission succeeds. That is, EFT Server's acceptance of the transmission does not mean that the transmission was successful.
EFT Server's implementation of AS2 considers the following transmissions permanent failures:
An inbound unencrypted transmission over plaintext HTTP protocol
An upload attempt to a folder to which the user does not have write permission
In each of these situations, the transmission is rejected automatically. An error is returned to the client, audited to the database, and can trigger an AS2 transaction failure event, if configured.
Redirecting AS2 transfers from HTTP to HTTPS
You can configure EFT Server to redirect HTTP connections to HTTPS. The redirect HTTP to HTTPS option affects incoming AS2 requests through HTTP. When you have configured redirection, the Server simply tells the connecting client that the resource was moved to the new HTTPS URL. The connecting client decides whether it will allow the redirect, because the new URL could be on different server. If the connecting AS2 client does not allow redirection to a different port, the connection will fail.