Creation and Processing of SSA

Once we create and deliver a SSA to a person, we must have a relative examining mechanism to check the legality of this SSA used in the incoming email.

Till now, we always talk about the spirit of SSA : only a specific sender can send emails to it. Now, we want to describe how we did it and what the reason is.

There are many ways may achieve this goal, but the most convenient way is storing all information in the MACS database. For example, we keep each allowed correspondent’s email address and the corresponding SSA in the MACS database.

When a SSA email arrives, we just search all pairs of allowed-correspondent and SSA in our database. If any pair matches the pair in the incoming SSA email header, we judge it as a legal email. Undoubtedly, the computation of this way is light, but the database storage cost will be very huge. For each correspondent of a user, MACS may need to keep a pair of the correspondent’s email address and the corresponding SSA.

We are not always sure how many correspondents a user has and how many users will be under a MACS. So we try to use a way which need not cost any database storage.

We encrypt data needed to be check into the SSA. Here we call the data a rule which

see whether the rule matches the sender email address in the mail header. Because data needed to be checked all transferred from the database to the SSA itself, this way will not cost any other database storage but only an encryption key of MACS.

Although this seems perfect, it still has a drawback. It cannot solve the guessing problem very well. After the happening of the guessing problem, indeed, we can update a brand-new SSA for others by changing the encryption key of MACS but that will make all other SSAs become invalid. We may adopt two ways after changing the encryption key of MACS. One is updating all other SSAs at the same time. Actually, it is impossible because MACS doesn’t know any information of correspondents.

Another way is keeping a number of old encryption keys at the same time. Adopting this way we won’t need to update all other SSAs immediately but cannot solve the guessing problem immediately either. Eventually, we still need to let all legitimate correspondents use new SSAs gradually, and discard all old encryption keys. So we will need another way to verify a sender’s legitimacy. If a sender sends to a SSA encrypted by an old key, we can send an email to him and wait his reply. If he replies, we will give him a new SSA. Actually, to all other correspondents of users in MACS, it’s an annoying solution, because they must change the SSA (if they don’t have MACS-support) only due to an unrelated person. Besides, what is the best time to discard an old encryption key will be a very troublesome problem, because there isn’t any information letting MACS know how many correspondents are still using an old SSA.

We proposed a better way to solve the problems mentioned above. In this way, MACS will create a N-byte (in our scheme, default value of N is 2) TTL (Time to Live) for each allowed correspondent of users before it calls MACS Generator to generate each SSA. This N-byte TTL will be involved in the creation of the SSA and

change the corresponding TTL. Of course, we need to store each TTL in the MACS database, but we use a way to let the storage cost be minimal as possible as it can. We will show what the way is and why we create and store each TTL in section 3.3.

Figure 13. The producing process of the Extension part of a SSA

Now, let’s see the producing process of a SSA first. The format of a SSA is

“^HTUuser_name.Extension@domain_name^UTH”. The major part of it which we need to create is the Extension part. Figure 13 shows the way how the MACS Generator generates the Extension part of a SSA. In the MACS, each user has a different encryption key.

To achieve the goal of specific sender addresses, the Extension is an encryption of the TTL and the correspondent’s email address which are encrypted by each user’s encryption key. Therefore, after decrypting the Extension part of a SSA, the MACS can examine whether the sender of this email is legal. Besides, the MACS encapsulates the correspondent’s email address into the SSA for saving the storage cost. The MACS doesn’t store any SSA in its database, because the rule has been encrypted into the SSA. The encryption algorithm, for example, the Advanced Encryption Standard (AES) with 256-bit key may be chosen for the creation of SSA.

length of a SSA being too long, we may decide to let the plaintext has the same size with the encryption block, e.g., if the length of an encryption block is 16-byte, we can combine the 2-byte TTL and the 14-byte hash value of the correspondent’s email address as our plaintext. This hash function can be chosen from any collision-free and one-way hash function, e.g., MD5. The main purpose of this hush function is to make the secret plaintext of the encryption algorithm. If an attacker gets any user’s encryption key and any SSA this user gave to his correspondent, this attacker still cannot know the correspondent’s email address. Till now, actually, the Extension is still not complete. In most cases, there may be some unprintable character in the final ciphertext. We can use Base64 [5] (encoding with character [A-Z][a-z][+][/]) to encode the ciphertext. If we choose the AES as the encryption algorithm, after encoding the 16-byte ciphertext, the length of it will become 22 bytes. Due to the case-insensitivity of the email address, a potential problem will occur if any email software changes the case of a SSA, e.g., lowercases all email addresses. For not taking any risk, we decide to choose Base32 [5] (encoding with character [A-Z][2-7]) encoding, although the 16-byte ciphertext will become a 26-byte text string.

Eventually, with this Extension and a separate symbol “.”, here the SSA is.

When MACS receives a SSA email which is sent to a local user, it will first use Base32 to decode the Extension part and get a ciphertext. Then it will decrypt the resulting ciphertext with the user’s encryption key and then get a plaintext. After that, MACS will find out the sender’s N-byte TTL in the database and then combine this N-byte TTL with the sender’s email address as a string. Finally, if this string matches the plaintext got from the Extension, MACS will judge this SSA email as a legitimate email and pass it into the incoming queue of the mail server. If it doesn’t, MACS will send an email back notifying the original sender his email has been discarded due to