Imagine if you hired someone (a receptionist) to look through it for you. Your receptionist's job would be to compare all incoming e-mail against the list of people you know, letting all that through immediately. To dump all the really obvious junk e-mail, and then to write back to anyone else, just to make sure there's a real someone answering the address, who really sent the first message.
...now imagine if you don't even have to pay this "Receptionist" minimum wage...
And now, the "real" FAQ list, which we have "seeded" with initial questions, and in fact they're a little jumbled up, having been collected from notes from various bits of research, but rest assured that we will improve the list as time permits.
The Internet has to handle more e-mail - at least at first. Your friends may have to respond to Receptionist's "confirmation request" messages if they want to send you e-mail - at least at first. If you subscribe to any mailing lists, you have to tell Receptionist about each one of them - at least at first.
Another "catch" is that we, the creators of Receptionist and the Receptionist Protocol, depend partly on your generosity to keep developing it. We would very much like to keep working on it, improving both the product line and the protocol specification, so that everyone can benefit from a reduction in their time that spam is allowed to waste. But we're giving away the product, and your use of it will not depend on us, not on a web site, not on anything. If you've downloaded, installed, and configured the individual-user version successfully and it is working for you, you are under no obligation to us, and it will continue to work for you whether we keep working on it or not. But we work even harder, in the hope that you'll appreciate it, and show us.
Surely a few will. Most won't - they can't afford to receive anywhere near as much e-mail as they want to send, they were never authorized to send that much anyway and being forced to receive Receptionist's confirmation requests increases their costs too much for the typical "hit and run" spammer to handle. Even the spammers who do install Receptionist or anything which gets through the confirmation process will be easier to track down, easier to complain about, and easier to make stop spamming you.
Actually, many someones did think of it years ago. I was among them. But in a way, we thought too much about it. Receptionist includes what is called a "closed-loop confirmation" system, and many similar systems implemented in the past have taken [extra] steps to make sure that it would be difficult for a program to complete the confirmation. After more thought and some difficult spammer-cost analysis, I realized that an even simpler system should have most (but not all) of the effect of such a complex one. Some spammers will be able to get their spam through to you. I expect Receptionist to block at least 40% of spam, but that's just a guess. It could go much higher, or lower, depending on how many people use Receptionist, how many build and use compatible programs, and how many spammers try to beat the system.
Because the protocol embodied in Receptionist requires that the sender of a message receive and reply to a message in return, it at least triples the workload of a spammer. It may almost triples the workload, in message counts, of the entire e-mail system, at least at first. But that's just automated systems. Our goal is to reduce the time lost to spam by humans. Humans like you.
Yes, in some cases that may happen - at least at first. When (and if) the protocol embodied in Receptionist eventually becomes widespread, Internet Service Providers (ISPs) will be able to take over portions of the workload from your own computer once they are ready to. I anticipate this will be a "value added" service offered eventually by most ISPs.
The purpose of Receptionist, and the Receptionist Protocol, is so that people can stop wasting as much HUMAN time and effort deciding which message is worth reading and which is clearly unneeded. Receptionist does this by mechanical means, but without the same probability of losing real e-mail that most spam-filters have.
Maybe.
But probably not by itself. What it will do is save Receptionist users
from wasting
quite as much time on spam. Since Receptionist is both a product and a protocol,
the Whole World is welcome to implement the protocol, so that the Whole World's
users are saved from wasting their time. After which perhaps the spammers will
give up. But that may be wishful thinking. Today's spammers may not be ethical,
but they are devious and somewhat resourceful. They will probably find a way to
adapt, even if it just means sending more and more spam to reach recipients who
are not Receptionist users.
Another advantage Receptionist will give to its users is that whatever small quantities of spam do get through the confirmation system will be from senders who can then be tracked down, because they had to have a fixed location, at least for a moment, in order to receive the confirmation request message. Therefore any spam which does manage to get through to Receptionist users will tend to be much more actionable, and the spammers sending it much more vulnerable.
In the (unlikely?) event that the Whole World one day uses the Receptionist protocol, it should be much easier to deal with whatever spammers remain, as it will then be essentially impossible for them to hide, if they want any of their junk e-mail to reach anyone's in-box. Once they can't hide, they can be tracked down, and they can have the access accounts they abuse taken away. Perhaps one day the world will be fortunate enough that the costs associated with spamming will prohibit anyone from doing it any more.
The design goal of Receptionist is to reduce the amount of HUMAN time that end-users waste, as they look through their in-boxes, separating useful e-mail from useless junk. Many, perhaps most, other anti-spam tools have among their goals the eventual stoppage of all spam. Very few other anti-spam tools have taken the step of actually sending additional (automated) e-mail in order to save time for the humans involved. The members of the team who developed Receptionist have been participating in the anti-spam community for many years, aware of many (if not most) of the other tools and tool-developers, and for most of this time it has been the desire of all of these people to not increase the load on the e-mail system just to deal with spam. The Receptionist team has decided to be willing to send and receive even more messages, use even more technology, and possibly even (slightly) increase the costs borne by the automated infrastructure of the Internet. We feel that the goal of saving HUMAN time is the purpose for which all these computers, routers, wires, fibers, and the whole of the Internet were put in place. We feel that it is not merely acceptable but actually desirable to devote more computation and communication resources to the goal of reducing wasted HUMAN time.
No, but we believe Receptionist will bring the same kinds of benefits. Receptionist requires the senders of e-mail to "confirm" that they are who they claim to be - or at least that they actually receive e-mail where they claim to. Receptionist will not allow incoming e-mail through to your in-box unless either the confirmation request message is received and replied to, or you, the user, tell Receptionist to allow a particular sender through without challenging.
Possibly.
However, anyone can simply install Receptionist, or any compatible software
(in "confirm only" mode if they don't want it to handle their incoming e-mail) to
confirm their own outgoing e-mail. Once it's installed on their end, they don't
have to use up any HUMAN time responding to confirmation request messages either.
While we regret that
we are asking everyone's correspondents to change their ways a little (by responding
to confirmation requests) we are also providing tools (Receptionist itself)
which they can use to automate the responding process.
If that happens, you have more choices than before. If you want to file a complaint with the spammer's ISP (or ISPs) you can use the Receptionist control messages as proof that the spammer not only sent you unwanted e-mail, but received and replied to your confirmation request. This makes it much more likely that the ISPs can take action against spammers. And whether you complain or not, you can ban the sender's address from getting through again. So that for each time a spammer does manages to get through to your in-box, they'll have to "use up" an address that really worked. Hopefully this time, they'll run out of accounts long before you run out of patience.
Of course that is a possibility. Especially if you drive is nearly full already. We feel that it is wise to retain incoming e-mail a minimum of one week before giving up on the confirmation message. Some folks only check their own e-mail about once a week, and it could easily take twice that amount of time for two such people to see a round-trip of the confirmation request and response messages. For this reason we recommend you retain incoming e-mail for a minimum of twice the longest period of time that you might take between picking up your e-mail. If you go on a two week vacation once a year, we feel it would be wise for you to retain at least four weeks of incoming e-mail before giving up on any confirmation messages.
Additionally, our client programming research has shown that it may in many cases be practical for unrecognized messages to be left on your provider's POP server, rather than downloading them at all.
Hardly! Once you have Receptionist working for you, you may add tasks to its workload. Currently there are a wide range of anti-spam resources on the Internet, and many of them can be used to add to the filtering capabilities of Receptionist. As the popularity of Receptionist grows, we also hope to add such online services ourselves, through our own servers. Eventually, we hope to have your Receptionist live up to the name as well as a human being would, and in some ways (such as speed) better than any human could.
But to make it free and easy for you to install and receive the first benefits of Receptionist, and so that your friends and correspondents can do the same (also so that they aren't burdened with the extra work of acknowledging everyone's confirmation requests) we have chosen to reserve those additional features for a non-free version, to be released soon.
Well, it must be admitted that such junk e-mail will still get through. However, by responding to the confirmation request, the spammer has documented the e-mail account they used. Almost every service provider on the Internet will cancel user accounts for the offense of spamming if sufficient evidence can be shown that the user is the real spammer.
No, but this is why Receptionist needs to process all your outgoing e-mail as well as incoming. What Receptionist does is store information about outgoing messages so that when a confirmation request arrives, Receptionist can check to make sure that message really was sent. If it was not, Receptionist will not acknowledge the request, and also it will log this event as an intrusion attempt. Depending on your choice of logging options, Receptionist may give you a message about the event.
If you did send that message, but not through Receptionist, then Receptionist will allow you to manually acknowledge that outgoing e-mail easily.
If you wish to install Receptionist in more than one location and want them all to communicate automatically with one another, you'll need an advanced (non-free) version.
First, you install it on the computer you use for e-mail. You configure it to pick up and send your e-mail, just like your current e-mail program does. You give Receptionist a few instructions, such as a list of your friends' e-mail addresses, and also (this is vital!) details about any e-mail lists that you subscribe to.
Then you reconfigure your e-mail program to pick up and send all your e-mail through Receptionist.
What Receptionist does is look at every incoming e-mail, compare it against several lists, such as the list of your friends, and let it through only if it meets one of the tests. If it doesn't, then Receptionist puts the incoming message "on hold" and sends a reply, effectively asking the caller "who may I say is calling?" If there's really someone at that e-mail address, they need only affirm that they did indeed send the initial message, and then Receptionist will release the "hold" and let the message through.
And when you send a message out, Receptionist takes a quick look at it, stores a little information about it, and sends it on its way. If the recipient of that message has Receptionist (or a compatible system), then your Receptionist will receive that confirmation request message, look up the message identifier to see if it really was sent out, and if so Receptionist will confirm it. As a user of Receptionist you don't need to see or respond to any of those request messages, Receptionist will look each one up in the stored data from your outgoing messages and will reply to those which you did actually send.
If your correspondents also use Receptionist or a compatible system, they don't ever have to see or handle the inquiries from your Receptionist either. And there will be still further advantages when your correspondents also Receptionists of their own, because "your people can talk to their people" and can arrange for even greater security between the two of you if you wish it. It's a simple matter of telling your receptionist to only accept messages which came through their Receptionist, and confirm any others (even though they're on your "friends" list)
Similar systems have been done, with varying degrees of success, but all fairly limited. We believe that the hold-ups are a result of the developers of those other systems OVERthinking the problems. Some of them send out similar "challenge" messages as replies to the unknown senders of incoming messages, but then they make the challenge too difficult for a program on the other end to respond to. It is our considered opinion that this is unnecessary extra work. We believe that very few, if any, spammers will bother to respond within the confirmation process, and those who do will be identifying themselves at the same time, making them dramatically more vulnerable to tracking down.
We also believe that part of the motivation for many of the other systems we have examined is profit - for which they have retained some degree of centralized control over their systems, such as a web site where correspondents must visit to confirm e-mail to let it go through. With Receptionist we are trying to make a difference first, and hopeful that our users will be pleased and supportive by their own choice.
Certainly there may be some senders of spam e-mail who will install Receptionist, or re-write their spam-blasting programs to do what Receptionist does. And if they do, they will be able to respond to your Receptionist's requests. They will have to receive the request message from your Receptionist, but once they do that, their spam will get through to your in-box. Unfortunate, but true. However, when you recognize a message as spam, you only need to tell your Receptionist, and then no future confirmation request messages will ever again be sent to that spammer's address. In order for that spammer to ever bother you again, they will have to open a new account, or at least create a new address, at which they can actually receive e-mail. Not only that, but if you should choose to complain about that spam, you not only have the spam itself, but you also have the e-mail address of someone who has actually accepted the responsibility for that spam. If you are someone who cares enough to try to get spammer's accounts disconnected, you will have much higher quality evidence than ever before to send to the spammer's service provider.
So yes, a trickle of spam can still get through, but even then you will be empowered by Receptionist to be able to do more about it than ever before.
Of course there are. First, and probably largest, your correspondents who don't have their own Receptionist (or compatible system) will occasionally have to read and reply to your Receptionist's inquiries. Some of your correspondents may be annoyed by these "extra" messages, and perhaps a few will refuse to bother with them. You won't see e-mail from them any more, that could be a serious drawback. But the messages themselves will carefully explain what is necessary in a reply message so that the original message will be released to you. We hope that your correspondents will find them easy to respond to. Unlike automated voice-mail "attendants" we plan to make all the messages from any Receptionist include very similar instructions to follow. Although if a user wants to change the messages, some customization will be possible.
Of course we also hope that your correspondents will find Receptionist interesting enough to investigate getting a Receptionist of their own. Then everybody wins and no person even has to handle the confirmation request messages!
Also, if you sometimes send e-mail from more than one computer, you will need a more advanced version of Receptionist, because you'll need one on each computer and they'll need to share information. Small-business and corporate versions of Receptionist are in the design stages, but not yet available. For now, the free version of Receptionist is designed just for single-user Windows computers. This is because we felt that we could do the most good, for the most people, by starting there, and giving away that version as "freeware/shareware/begware" - if you like it, we hope that you'll want to pay a reasonable price to help us continue to develop it, but even if not, you are welcome to use it for free, for as long as you like.