AS2 transfers can have more than a simple success or failure outcome. For example, an outbound AS2 file transfer may succeed, but no 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.) received from the remote host. This could be considered an outright failure in some cases. Another example may include a successful file send followed by MDN received, but the received MDN’s signature cannot be verified. Some AS2 systems do not consider these partial failures as an overall failure, but others will. For example, a remote host may accept an inbound file and create a log that its signature was bad or had other issues, yet still accept the file. Likewise, EFT Server by default 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.
EFT Server rejects inbound unencrypted transmissions over plaintext HTTP protocol, and an upload attempt to a folder to which the user has no write permissions. EFT Server considers these permanent failures.
The topics below provide information and procedures for defining Event Rules to automate AS2 transfer activities. For details of defining Event Rules, refer to Creating Event Rules.