Like any other ASx file transfer, AS1 file transfers typically require both sides of the exchange to trade SSL certificates and specific "trading partner" names before any transfers can take place. AS1 trading partner names must really be email addresses. (AS1 is the only ASx protocol that contains this requirement.)
You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS1 message. (Both the encryption and signing steps are optional, but should be used when possible.)
You send the AS1 message to an email server via SMTP. Often, this will be your local email server. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
If the AS1 message was sent to your local email server, it will now deliver it to your partner's email server using the SMTP protocol. Along the way your AS1 message may traverse several intermediate email servers as it is relayed across the Internet or corporate email infrastructure. (Cleartext message headers are rarely protected with SSL transport if relay servers are involved.) This step will be skipped if the AS1 message was delivered directly to your partner's email server in step #2.
Your partner will retrieve your AS1 message off your partner's local email server using the POP3 protocol. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate. If the message is signed, your partner will validate your signature using the public key on your SSL certificate. Your partner will also use the contents of the AS1 message to verify that the data file they now have is identical to the data file you sent them.
If you requested an MDN delivery receipt for your data file, your partner will calculate a cryptographic hash from the data file they received, sign the hash (and some other information) with the private key on their SSL certificate and create an MDN delivery receipt message. (The signing step is optional and controlled by the original message sender.)
Your partner will send his/her MDN delivery receipt message to an email server via SMTP. Often, this will be your partner's local email server. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
If the MDN delivery receipt message were sent to your partner's local email server, it will now deliver it to your email server using the SMTP protocol. Along the way your partner's MDN delivery receipt message may traverse several intermediate email servers as it is relayed across the Internet or corporate email infrastructure. (The cleartext MDN delivery receipt message is rarely protected with SSL transport if relay servers are involved.) This step will be skipped if the MDN delivery receipt message was delivered directly to your email server in step #7.
You will retrieve your partner's MDN delivery receipt message off your local email server using the POP3 protocol. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
You will inspect your partner's MDN delivery receipt message, making sure that you can verify his/her signature using the public key on your partner's SSL certificate and that the cryptographic hash calculated from your partner's copy of your data file matches the same hash calculation from your original data file.
Variations
Direct connections to each mail server - AS1 clients can usually be configured to connect directly to your partner's email server rather than your local email server. Doing so avoids multiple "relay hops" but usually involves some additional firewall configuration.
Shared mail server - Your organization and your partner could agree to use different email accounts on the same physical email server, hosted at your data center, your partner's data center, or any other email server in the world. Doing so avoids multiple "relay hops" but usually involves some additional firewall configuration.
