New Permission Keys are randomly generated and issued from a key issuing facility. The embedded codes of new keys are recorded along with the details of their provisioning. These details may include: issuing facility, key form, time, and expiry date, and if known, who the key was issued to.

It can be seen from the figure below that there are three different types of key issuing facilities, each capable of issuing different forms of keys, and each positioned to reduce one or more types of lost message.

The types of key issuing facilities are designed to cater for each of the acquisition methods that were described previously, and are as follows:

• Outbound Message Insertion,
• AJAX Web Service, and
• Manual Key Issuing Facility (Client Interface)

Outbound Message Insertion

The purpose of the Outbound Message Insertion module is to intercept all out going messages and to embed permission keys in to all instances of the protected user's email address.  Usually implemented at the out bound SMTP gateway, its implementation is relatively easy and simple, requiring no user interaction, and no user interface.

Typically inserts DNA/CaseKey Hybrid Keys, but if high speed in place stream insertion is required, then may insert only CaseKeys.

AJAX Web Service

The purpose of the AJAX Web Service Key Issuing module is to dynamically insert a permission keyed instance of the protected user's email address in to the contents of a web page - typically within a mailto tag.

While it may be unadvisable to publish an email address on a web page, users still do it. If the user must publish their email address then at least by inserting a permission key we can guarantee delivery of legitimate messages that flow from it. This service also gives us the opportunity to include obfuscate techniques to at least make the address as difficult as possible to harvest.

Permission Keys that are published on web pages should be set to "auto-expire" - we recommend setting them to auto-expire after 7 days. The AJAX service should automatically cycle the Permission Key for a web site on a daily basis - one new unique key would be issued each day. This allows the site visitor 7 days to use the CaseKey before it expires.

This works because the nature of usage of an "on-line published" email address is that the address will be used at the time of issue. A user will click a "mailto:" link and typically send the message within a few days at the most. However, Spambots take time to harvest messages, sell the lists, and finally send the spam sometime later, by which time the CaseKey has expired.

Permission Keys do not block Spam, they detect false positives. Even if the user were to keep the CaseKeyed email address and to use it after it had expired then their message would be no worse off than it was sent prior to implementation of the Permission Keys system. On the other hand however, Permission Keys technology will ensure that for users who do send before the Key Expires, that their message will not be mistaken for spam.

Note: In user feedback dependant systems Permission Keys that are set to auto expire should be excluded from ‘is not Spam' voting and their use should be limited to ensuring that a message is not placed in the user's Spam folder.

Typically issues Plus Addressing/CaseKey Hybrid Keys, if the protected user's mail system supports it, otherwise a CaseKey.

Client Interface

A manual ad-hoc permission key issuing facility is required to facilitate the use of permission key embedded email addresses with Web Forms and for off-line uses - such as printing on business cards.

Ideally such a facility will allow the user to indicate the purpose of the key, and will issue the address encoded in an appropriate form for the indicated purpose.