Disposable email address
|This article needs additional citations for verification. (December 2010) (Learn how and when to remove this template message)|
Disposable email addressing (DEA) refers to an approach where a unique email address is used for every contact or entity. The benefit is that if anyone compromises the address or utilises it in connection with email abuse, the address owner can easily cancel (or "dispose" of) it without affecting any of their other contacts.
Such disposable addresses are generally provided by a service company (paid or free) that forwards mail from the DEA to the actual address, but email sub-addressing techniques can also be used to provide a subset of similar advantages.
Disposable email addressing sets up a different, unique email address for every sender/recipient combination. It operates most usefully in scenarios where someone may sell or release an email address to spam lists or to other unscrupulous entities. The most common situations of this type involve online registration for sites offering discussion groups, bulletin boards, chat rooms, online shopping, and file hosting services. In a time when email spam has become an everyday nuisance, and when identity theft threatens, DEAs can serve as a convenient tool for protecting Internet users.
Disposable email addresses can be cancelled if someone starts to use the address in a manner that was not intended by the creator. Examples are the accidental release of an email to a spam list, or if the address was procured by spammers. Alternatively, the user may simply decide not to receive further correspondence from the sender. Whatever the cause, DEA allows the address owner to take unilateral action by simply cancelling the address in question. Later, the owner can determine whether to update the recipient or not.
Disposable email addresses typically forward to one or more real email mailboxes where the owner receives and reads messages. The contact with whom a DEA is shared never learns the real email address of the user. If a database manages the DEA, it can also quickly identify the expected sender of each message by retrieving the associated contact name of each unique DEA. Used properly, DEA can also help identify which recipients handle email addresses in a careless or illegitimate manner. Moreover, it can serve as a good tool for spotting fake messages or phishers.
Advantages over traditional emailEdit
Ideally, owners share a DEA once with each contact/entity. Thus, if the DEA should ever change, only one entity needs to be updated. By comparison, the traditional practice of giving the same email address to multiple recipients means that if that address subsequently changes, many legitimate recipients will need to receive notification of the change and to update their records – a potentially tedious process.
Additionally, because access has been narrowed down to one contact, that entity then becomes the most likely point of compromise for any spam that account receives (see "filtering" below for exceptions). This allows users to determine firsthand the trustworthiness of the people they share their DEAs with. "Safe" DEAs that have not been abused can be forwarded to a real email account, while messages sent to "compromised" DEAs can be routed to a special folder, sent to the trash, held for spam filtering, or returned as undeliverable if the DEA is deleted outright.
Further, because DEAs serve as a layer of indirection between the sender and recipient, if the DEA user's actual email address changes, for instance because of moving from a university address to a local ISP, then the user need only update the DEA service provider about the change, and all outstanding DEAs will continue to function without updating.
A number of email systems support "sub-addressing" (also known as "plus" or "tagged" addressing) where a tag can be appended to the "local part" of an email address – the part to the left of the "@" - but with the modified address(es) being an alias to the unmodified address. For example, the address email@example.com denotes the same delivery address as firstname.lastname@example.org. The text of the tag may be used to apply filtering, or to create single-use addresses.
Multiple email aliasesEdit
Another approach is to register one main and many auxiliary email addresses, which will forward all mail to the main address, i.e., the auxiliaries are used as aliases of the main address. The advantage of this approach is that the user can easily detect which auxiliary email is 'leaking' with spam and block or dispose it.
Some services require additional time to set up forwarding but others allow to create new addresses "on the fly" without registering them with the service in advance. However, this method allows storage and access of all emails from a single main account, although to manage forwarding for some services the user has to remember the password for each alias.
A variation is to use a catch-all address, then forward to the real mailbox using wildcards. Many mail servers allow the use of '*', meaning 'any number of characters'. This makes the whitelist automatic and only requires the administrator to update the blacklist occasionally. In effect the user has one address, but it contains wild cards, e.g.; 'email@example.com', which will match any incoming address that starts with 'me.' and ends with '@my.domain'. This is very similar to the '+' notation but may be even less obvious since the address appears to be completely normal.
Restrictions by site administratorsEdit
Many forum and wiki administrators dislike DEAs because they obfuscate the identity of the members and make maintaining member control difficult. As an example, trolls, vandals and other users that may have been banned may use throwaway email addresses to get around the ban. Using a DEA provider only makes this easier; the same convenience with which a person may create a DEA to filter spam also applies to trolls. As a result, forum, wiki administrators, blog owners, and indeed any public site requiring user names may have a compelling reason to ban DEAs. Site operators expecting to generate revenue by selling the user email addresses they gather may choose to ban DEAs as well due to the low market value of such addresses. There are several free lists available to help detect DEA domains as well as managed services.
Banning DEAs might not be as effective at deterring undesirable users as the administrators might hope – spammers, vandals and trolls who routinely engage in such activities can easily generate brand new email addresses, even legitimate-looking ones, using throwaway domains or creating new accounts with free email services. This would be more of a problem for legitimate DEA users, for whom the concept of a "real" or "permanent" address may well not exist, and demands for one are strange, suspicious and inconvenient, and creating a differently structured alias or account may cause varying degrees of hassle.
More effective techniques for controlling undesirables without inconveniences to legitimate DEA users might include: recognizing legitimate DEAs for what they are (they usually have a proper domain and a fixed prefix or suffix), distinguishing them from short-lived, random throwaway address patterns or domains used by undesirables, wildcard banning (e.g., if a real person John Smith, using DEA, needs to be banned, he can be banned as john.smith*@(domain) or even *@(domain), based on their DEA pattern).
As with any kind of threat and defence measures, no attempts to use or thwart DEAs are foolproof – any filtering method is bound to result in some false positives (legitimate users getting banned), and some false negatives (undesirables getting through, and legitimate users managing to come up with a DEA pattern getting around limitations imposed by site administrators). This is because the email address may be partly or fully defined by the user, made to appear as "permanent"-looking as needed, or made to avoid a particular pattern, defeating any filtering because for all intents and purposes it is not different from a permanent one, despite being limited to one purpose.
As a counterbalance to the risks of asking a user to give a "permanent" email address in a publicly accessible site, administrators have the option to prevent, the publication of users' email addresses or to give users the option of hiding their address. An "email this user" script can be used to allow communication with the user without the sender knowing his email address. This provides users with some minimal protection from spam and allows them to use real email addresses, which may make a ban on DEAs easier for users to accept. The problem is when the website itself is hacked, and the real addresses and other personal information is stolen, or when the website changes owners and email policies are changed without notifying the user, or if the website was set up from the beginning with the intention to spam the user.
Many sites offer free disposable email addresses that expire after a short amount of time, usually between ten minutes and a week. It's entirely possible that the business model of these sites is to serve the users targeted ads after reading their emails or to sell the user's emails to the highest bidder. A website could even lock a user out of their email address and then sell the still-functioning account, allowing for impersonation or the theft of accounts by using Password notification emails.
- "Disposable e-mail addresses foil marketing plans". Network World. 2006-12-04. Retrieved 2007-02-02.
- "Using an address alias". google.com.
- "Disposable addresses in Yahoo Mail – Yahoo Help – SLN3523". help.yahoo.com.
- "Outlook.com supports simpler "+" email aliases too". Within Windows.
- "Plus addressing and subdomain addressing". fastmail.fm.
- "Yopmail - Disposable Email Account - Temporary Email". www.yopmail.info. Retrieved 2017-05-28.
- "Disposable E-mail Addresses". PC Magazine. 2004-03-22. Retrieved 2007-02-06.
- "Successful Forum Tip #3 – Troll Prevention and Extermination". 2004-08-09. Retrieved 2007-02-02.
- "Add New Ban". SMF 1.1 Online Manual. Simple Machines LLC. Retrieved 2007-02-02.
- "Email Options". vBulletin Manual. Jelsoft Enterprises Ltd. Retrieved 2007-02-02.