When an email comes into our MACS, more time will be needed to process this email, e.g. decode and decrypt. Therefore, we want to know how much percentage of time was increased. We built our MACS prototype by modifying one component of the Postfix version 2.1. This component is called “Cleanup” in the architecture of the Postfix and is responsible for receiving all emails come from Local or Internet and then delivering them to the incoming queue of the Postfix. For evaluating the effectiveness and efficiency of our MACS prototype, we compared the difference between the original mail server and the new mail server with our MACS prototype.
We prepared two computers and used the Postfix 2.1 official release as our mail server. These two computers were our sender site and receiver site. The sender site was equipped with AMD Athlon XP2800+, 2 G RAM running FreeBSD 4.10-STABLE. The receiver site was equipped with double Intel P3 733 MBHz processors, 256 MB RAM running Linux 2.4.20 (Red Hat 9.0). We let the receiver site install the Postfix 2.1 without and with our MACS individually and let the sender site send 1000 emails sequentially as fast as it can to the receiver.
Figure 15 shows the total cost of processing 1000 emails in the “Cleanup”
component in two situation : mail server without MACS and with MACS. The x-axis stands for the number of processed emails and the y-axis stands for the total time spent in the “Cleanup” component. In the situation without MACS (original Cleanup), passing 1000 emails through the “Cleanup” component totally cost 10.93427 seconds in average. Passing 1000 SSA emails through our MACS (new Cleanup) totally cost 12.96729 seconds in average. Due to the decoding and decryption to a SSA, our
For processing a single email, this result is not satisfying, but actually, to the whole mail server, our MACS won’t down too much efficiency. Figure 16 shows this result. The x-axis stands for the number of processed emails and the y-axis stands for how much time passed when “Cleanup” finished processing emails. In the situation without MACS, 182 seconds passed when “Cleanup” finished the 1000PthP email. In the situation with MACS, 195 seconds passed when “Cleanup” finished the 1000PthP email.
To the whole mail server, it only increased 7% on the cost. We think it’s an acceptable result.
Figure 15. Total time spent on processing emails in mail server and mail server with MACS
Figure 16. Time passed from the first to the 1000PthP email in mail server and mail server with MACS
In addition to the efficiency, we evaluate the database storage cost of the MACS by a specific example. Suppose there are 1,000,000 users in a MACS and each user has 1,000 correspondents. For a user in the MACS, we need to count the size of encryption key, the size of Index Table of TTL and the size of SSA Table. Each user’s encryption key is 32-byte. A TTL for each correspondent is 2-byte. Each row of a SSA Table is put two strings : correspondent’s email address and the SSA the correspondent gives to the user. We suppose the size of a normal email address is 30 bytes and the size of a SSA is (30+1+26) bytes in average. Besides, for a whole MACS, we need to count its 32-byte encryption key and the size of all Table of T (T0, T1, T2, T3). Each mark in a Table of T is 1 bit : 0 or 1, so there are total N bit used in a Table of T. We suppose the maximum N in the Table of T will be (number of users)
average) * (number of days the Token T exists).
MACS’s encryption key 32 bytes 32 bytes
Table of T0 1 bit * #u * 50 * 2 12.5 MB
Table of T1 1 bit * #u * 200 * 7 175 MB
Table of T2 1 bit * #u * 25 * 7 21.875 MB
Table of T3 1 bit * #u * 25 * 7 21.875 MB
#u = number of users = 1,000,000
#c = number of correspondents each user has = 1,000
Table 1. The storage cost in database of the MACS
To the Table of T0, we suppose a user sends 50 normal emails out everyday and our MACS only keeps each T0 for 2 days. That is because if the receiver site doesn’t have MACS-support, the T0 will never come back, but if the receiver site has MACS-support, the T0 will come back soon with the Registry Require Email. So, for the T0, two days will be much sufficient. To the Table of T1, we suppose a user receives 200 normal emails everyday (including spam mails) in average and our MACS keeps each T1 for a week. It means the correspondent may be able to reply the
“Registry Require Email” during one week. To the Table of T2 and T3, we suppose a MACS may receive 25 “Registry Require Email”s and 25 “Re: Registry Require Email”s everyday in average and our MACS will keep each T2 or T3 for a week. This means the user may be able to decide whether he gives a SSA to the correspondent
Table 1 shows the maximal storage cost of the MACS which are used by 1,000,000 users and each user has 1,000 correspondents. We noticed that all
“Correspondent’s SSA Table”s cost the database 87 GB for achieving the goal of transparency. Actually, we could reduce the storage cost by using a collision-free hash function like the Sequence Table of TTL or the Index Table of TTL we described in section 3.3. Through the hash function, we can shorten the length of the correspondent’s email address substantially, even let it disappear. Furthermore, despite the large database storage cost for achieving the transparency, it is still acceptable for current disk storage.
Table 2. Comparison between spam-filtering schemes
Table 2 shows the comparison between all kinds of spam-filtering schemes. Due to the probability theory, even though a Bayesian-based scheme can improve its accuracy on judging spam to 99%, the false negative and false positive problem will still occur. False Negative problem also occurs in TMDA, because if a spammer answers the puzzle in the challenge-email, users in TMDA system will still receive
MACS costs a little more database storage for solving the guessing problem well but SPA cannot solve it. Besides, in the scheme of SPA, users still need to see bulks of spam finding whose emails they want to receive and then create the corresponding SPAs for them. Moreover, users in TMDA may not receive automatic-sending emails like some notifying emails sent by a sending program because a machine cannot solve their puzzles. Finally, if a user receives a SPA or a TMDA, he must keep it or change the old email address of the corresponding alias by himself. The worst is that if he doesn’t keep them with, he cannot send emails to those SPAs or TMDAs by the Mail User Agent (MUA) in other person’s computer. So, transparency is also a feature of the MACS.