3.2. The quarantine area

The online quarantine facility was intended as a core component of the service right from the start. There were many reasons why having this quarantine available was useful for both users and the maintainers, some of those reasons include:

The quarantine keeps us honest.

Having the quarantine of rejected messages available to end-users means that we, as service operators, couldn't lie to them.

We could not say "We blocked 20 million pieces of SPAM on your behalf", because they'd look in their quarantine and see that wasn't the case.

Although we'd never suggest any responsible company would lie to users it is definitely the case that removing the possability is a good thing.

The quarantine provided a means of tracking success.

Although we kept our own statistics, and presented some to users, having the visible quarantine allowed users to see their capture rates in a very real fashion.

Allowing users to support themselves.

By placing rejected mail in a location that users could access they were placed in a position where they could fix mistakes themselves.

Although any mistake was a regrettable occurance, and we didn't wish to force users to clean up our mistakes themselves, it was definitely a good thing that users weren't beholden to other people.

Having a quarantine provided a good corpus of data.

Although we could keep track of patterns ourselves using private data and statistics it was always useful to be able to examine rejected mail and spot new trends and experiment with new techniques of identifying unwelcome email.

Because of the way we operated we did have to allow every incoming SMTP transaction to execute from start to finish, but identify SPAM early in the process would be useful as it would allow us to avoid running the more heavyweight processes.

It presented a useful reassurance.

Email is important and can be crucial for many companies, and the fear of losing legitimate mail can sometimes be palpable.

By committing to archive rejected mail, even though that imposed significant technical challenges, we were ultimately providing something that was highly desirable for many of our users. (See the related discussion in Appendix A.)