deliverMail

void deliverMail(byte[] mail, String routingHint, Function<byte[], byte[]> callback)

Delivers the given encrypted mail bytes to the enclave. The enclave is required to override and implement receiveMail to receive it. If the enclave throws an exception it will be rethrown. It's up to the caller to decide what to do with mails that don't seem to be handled properly: discarding it and logging an error is a simple option, or alternatively queuing it to disk in anticipation of a bug fix or upgrade is also workable.

It's possible the callback provided to start will receive a MailCommand.PostMail on the same thread, requesting mail to be sent back in response. However, it's also possible the enclave will hold the mail without requesting any action.

If the enclave is not unable to decrypt the mail bytes then a MailDecryptionException is thrown. This can happen if the mail is not encrypted to the enclave's key, which will most likely occur if the enclave was restarted and the client had used the enclave's old encryption key. In such a scenerio the client must be informed so that it re-send the mail using the enclave's new encryption key.

Parameters

mail

The encrypted mail received from a remote client.

routingHint

An arbitrary bit of data identifying the sender on the host side. The enclave can pass this back through to MailCommand.PostMail to ask the host to deliver the reply to the right location.

callback

If the enclave calls Enclave.callUntrustedHost then the bytes will be passed to this object for consumption and generation of the response.

Throws

If the enclave has not provided an implementation for receiveMail.

If the enclave was unable to decrypt the mail due to either key mismatch or corrupted mail bytes.

If the host has not been started.

void deliverMail(byte[] mail, String routingHint)

Delivers the given encrypted mail bytes to the enclave. The enclave is required to override and implement receiveMail to receive it. If the enclave throws an exception it will be rethrown. It's up to the caller to decide what to do with mails that don't seem to be handled properly: discarding it and logging an error is a simple option, or alternatively queuing it to disk in anticipation of a bug fix or upgrade is also workable.

It's possible the callback provided to start will receive a MailCommand.PostMail on the same thread, requesting mail to be sent back in response. However, it's also possible the enclave will hold the mail without requesting any action.

If the enclave is not unable to decrypt the mail bytes then a MailDecryptionException is thrown. This can happen if the mail is not encrypted to the enclave's key, which will most likely occur if the enclave was restarted and the client had used the enclave's old encryption key. In such a scenerio the client must be informed so that it re-send the mail using the enclave's new encryption key.

Note: The enclave does not have the option of using Enclave.callUntrustedHost for sending bytes back to the host. Use the overload which takes in a callback Function instead.

Parameters

mail

the encrypted mail received from a remote client.

routingHint

An arbitrary bit of data identifying the sender on the host side. The enclave can pass this back through to MailCommand.PostMail to ask the host to deliver the reply to the right location.

Throws

If the enclave has not provided an implementation for receiveMail.

If the enclave was unable to decrypt the mail due to either key mismatch or corrupted mail bytes.

If the host has not been started.