This post doesn’t relate to my HCI research work but instead details an idea I had about new standards which could be put in place to stop spam.  The crux of the idea is that all e-mail accounts become required to use safe/white lists.  Could improved functionality of safe lists make this possible?

What’s the idea?

Safe lists for all!

The idea is to ensure all e-mail accounts use safe lists.  A safe list is a collection of other e-mail address that a user is willing to accept messages from.  The use of safe lists is not a new idea.  Many e-mail services at the moment offer safe list options.  However, adoption of safe lists by e-mail isn’t wide spread since users have to opt-in to their use.  Many users may not wish to opt-in due to their fear of the safe list causing them to miss an important message.

If safe lists were made the required method of message filtering on all e-mail accounts, spammers would have a much harder time getting in contact with people.  However, the problems caused by the increased likelihood of important messages being missed would counter the benefits safe lists bring.  Therefore, a method of improving safe list which makes them easier to manage and add addresses to is needed.

Advanced safe list functions:

Request verification.

I propose a method in which an owner of one account can send a request to be added to a recipient’s safe list before messaging.  This is similar to the friend system used on many social networks where two parties must first approve each other before being able to send messages back and forth.  Once a request is accepted both parties appear in each others’ safe list.

If following this approach, it is important to make sure that the request system doesn’t allow for spam. Therefore, requests should have options to add the sender to the safe list, ignore the request and ignore all requests from the sender.  Requests should be minimal, not allowing any links or additional text beyond the sender’s identity to be included in them.  A verified account approach, similar to that used by twitter, could be used to ensure nobody can impersonate well-known companies when making these requests.

If an open standard is used then when a user creates a new account with a website, part of the sign up process can involve accepting the site’s associated e-mail address onto their safe list.

Handling unverified messages.

Users should be able to modify their safe lists so that they can remove addresses if they no longer wish to receive messages from them.  In addition to this, users should be able to determine what happens to messages from those not in their safe list.  For example, users could create an auto-reply asking that the sender makes a safe-list request.

If safe lists were used more widely, users may be more mindful to ensure that they are an approved contact by someone before sending them a message – diminishing the possibility of an important message being filtered.  In addition to this, a more functional safe list which can inform a sender that their message has not got through will also ensure fewer important messages are missed.

Advantages?

Less spam in the world!

With widespread use of safe lists no one would receive messages from addresses they had not verified.  If people don’t verify spammers they won’t get spam.  With no spam getting through to anyone the spammers may get the message and give up, though goodness knows what they would move onto next.

Less spam = less phishing & viruses.

With little to no spam there would be fewer phishing incidents and fraud taking place through e-mail.  In addition to this, the spread of computer viruses would be severely crippled since e-mail is currently the number 1 way for malicious software to be spread.  This could lead to smaller bot nets and in turn, less spam.

Disadvantages?

More missed mail.

More mail may not reach its intended recipients due the sender not being on their safe list.  Hopefully the use of features such as automated replies and verification requests would minimise the number of cases where an important message does not eventually get through.

Public e-mails.

There are some e-mail accounts though which are intended to receive e-mails from many unknown addresses.  These public addresses are usually employed by people or organisations for receiving enquiries from the public.  These accounts could have contact-based white lists disabled so that any message sent to it is accepted, this however leaves them open to spam, thus undermining the possibility of spammers having no e-mail targets left.

A possible solution to this is to use a different form of safe list for these accounts.  A safe list which allows for specific sources of-email (not the sender’s address but the method they used to send the message) to be added such as web-based forms and specific pieces of software.  This way, messages from anyone can be sent to the account but only through verified sources.  If these sources use a form of human-verification then they will not facilitate spam while allowing any person to send messages through them.

For example, a company’s public feedback e-mail address could have a form on the company’s website placed on its safe list.  If the form uses a human-verification test, such as a captcha, then anyone but bots can send messages to the account via the form.

Could this idea go further?

For the phone.

The required use of safe lists could be applied to other forms of communication, I have previously posted an article about their use on phones.  If a user employs a safe list on their phone and e-mail it would make sense to combine both of these lists to reduce redundancy.  If a user is willing to accept phone calls from a specific person or organisation then it could be assumed that they may also wish to accept e-mails from them.

Unified safe list accounts.

A  system of managing a combined phone and e-mail safe list could be offered through the use of a unified account.  The user should be able to manage this unified safe list online.  With a phone capable of connecting to the internet and downloading an updated white list, a user could manage who can contact them through both phone and e-mail.

Group rules:

The assumption that because someone wishes to receive e-mails from a specific person or organisation they will be happy accepting calls from them cannot be assumed to be always true.  To accommodate for this the use of rules could be employed.  With these a user can define how a specific contact can get in touch.

There may be multiple contacts who the user wishes to manage in the same way (e.g. a group of users they are willing to accept e-mails from but not phone calls).  Contacts could be grouped and rules applied to the groups rather than to individual contacts.  This is similar to how several existing filtering systems currently work, such as the avast phone app.

Group rules could be made more specific than just determining how a contact is able get in touch, they could also determine when.  For example a user could create a group of contacts for friends who can contact at any time during the day but not at night to escape drunk dials.  However, to make sure late night emergency calls from relatives are not missed the user could create a grouping for family who can call at any time.

E-mail addresses to replace phone numbers.

With the use of unified accounts for contacts, e-mail addresses could be used to phone someone (similar to the workings of several VOIP services).  E-mail addresses could replace phone numbers if this approach becomes widespread which is beneficial due to their readability and memorability.  This would aid communication as users would only need to share one piece of information with others for them to be able to communicate with each other.  With the use of rules users can manage who is able to contact them with this information and how.

Safe lists for post?

Taking this idea even further, safe lists could be applied to physical mail.  If a unified account has a postal address associated with it, the account holder could control who would be able to see it through the use of group rules.  The account holder could only allow couriers and postal services to see their postal information meaning that they wouldn’t have to share these details with other parties, such as online shops and traders.

As mentioned previously in regard to phones, a user’s postal address could be replaced by their e-mail address.  When being sent a package the sender should be on the recipient’s white list and authenticated for physical mail.  In addition to this the courier or postal service carrying intended to make the delivery should be white-listed and authenticated to see the recipient’s physical address.  If the item is being sent is something bought online, part of the purchase process could be the automated safe listing of the sender and courier.  The sender gets the package out to the courier or postal service with both the recipient’s and their own e-mail addresses on it (with who is the sender and who is the recipient clearly marked).  The courier/postal service can check online to ensure that the recipient has verified the sender for physical mail and if everything is ok they can then retrieve the recipient’s postal address.   This would reduce the number of organisations that an online shopper needs to share their postal address with and could cut down on junk mail if it became the standard for physical mail.

How could this be done?

Agreeing on a standard.

Some of the additional ideas featured in the last section, specifically those relating to the use of safe lists with physical mail, would require a lot of time and work to be put in place.  However, the basic concept of using safe lists for all e-mail accounts could be done in a relatively quick and simple manner.

For this idea to be effective (i.e. enough e-mail users adopting safelists to deter spammers and encourage corporations to adopt their use) the majority of e-mail providers would need to adhere to a universal standard.  This could be outlined as an ISO once the finer details are agreed on.  Any of the large companies deciding on a different standard which is incompatible with the standards agreed on by others could cause problems.

Compatibility with current e-mail practices.

Total adoption of safe lists cannot be expected so backwards compatibility with existing e-mail address will need to be considered.   This shouldn’t be too problematic in both upgrading existing e-mails to use safe lists and in allowing any e-mail address to make safe list requests.

Is that it?

Yup.

Apologies for rambling on and not including enough references, diagrams, etc.  As I mentioned at the start of this article, system security lies outside my usual research topic.  This isn’t my area of expertise and I would be interested to see what those more in the know think.  I’d also be interested in knowing what other lay persons think as well.  Would you be willing to accept a safe list only approach if the additional functions proposed were implemented?  How could this idea be improved upon?  Would making a change of this magnitude to something such as widely used as e-mail be even possible?  Your views (not spam) are welcome.