The mail msg ACK implementation is currently in a branch because of a few issues when a user tries to send to multiple recipients. In the current system, when sending to multiple recipients in normal "broadcast" email mode, a separate encrypted message must be generated for each recipient (using that person's public key). Each such message is separately acknowledged. The problem is, how to handle these separate ACK messages for one initial message from user.
Details on problems and old ideas for resolving them:
1) When receiving each ACK, code needs to remember which recipient it was sending to and restart sending at that point. For example, we send to A, get an ACK, send to B, fail to get an ACK (due to either timeout or lost connection to mail server). Currently, we break connection to server, reconnect, and restart sending the whole message, starting with A on the failed ACK, but we should only resend to B in this case (and anyone after B that we haven't yet sent to).
2) We need to show the state of the message in the pending mailbox to indicate which users have successfully received the message and which haven't.
New idea for resolving this issue:
Instead of sending a separate message to each recipient, we send one message. The header of the message encodes the number of recipients, followed by a separate encrypted key for each of the recipients. When a client receives this message, it will try each recipient "key slot" to see if it can open that slot with one of it's private keys to get the symmetric key to read the message.
This method has a number of advantages over the previous method:
1) it resolves the issues with ACKing, since only one message is sent
2) it reduces network bandwidth and data storage requirements
The only disadvantage is it indicates the number of recipients, but it's quite possible this could be deduced by a peer on the network in the old method, just by looking for messages of roughly the same size at around the same time.
The mail msg ACK implementation is currently in a branch because of a few issues when a user tries to send to multiple recipients. In the current system, when sending to multiple recipients in normal "broadcast" email mode, a separate encrypted message must be generated for each recipient (using that person's public key). Each such message is separately acknowledged. The problem is, how to handle these separate ACK messages for one initial message from user.
Details on problems and old ideas for resolving them: 1) When receiving each ACK, code needs to remember which recipient it was sending to and restart sending at that point. For example, we send to A, get an ACK, send to B, fail to get an ACK (due to either timeout or lost connection to mail server). Currently, we break connection to server, reconnect, and restart sending the whole message, starting with A on the failed ACK, but we should only resend to B in this case (and anyone after B that we haven't yet sent to). 2) We need to show the state of the message in the pending mailbox to indicate which users have successfully received the message and which haven't.
New idea for resolving this issue: Instead of sending a separate message to each recipient, we send one message. The header of the message encodes the number of recipients, followed by a separate encrypted key for each of the recipients. When a client receives this message, it will try each recipient "key slot" to see if it can open that slot with one of it's private keys to get the symmetric key to read the message. This method has a number of advantages over the previous method: 1) it resolves the issues with ACKing, since only one message is sent 2) it reduces network bandwidth and data storage requirements The only disadvantage is it indicates the number of recipients, but it's quite possible this could be deduced by a peer on the network in the old method, just by looking for messages of roughly the same size at around the same time.