This section is still under development.

E-mail travels over an Internet protocol called SMTP - Simple Mail Transport Protocol.  This protocol describes methods by which mail servers move messages around, eventually delivering them to someone's e-mail in-box. If compared to postal mail, the role played by SMTP might be compared to the post office (handling) and how they use the information (addresses) printed on the envelope to decide where to deliver it. What's inside the envelope is in most ways independent of SMTP.

Unfortunately, there's nothing in e-mail comparable to the postage on a physical envelope - everyone shares the costs, so it's as if everything arrives "postage due" (or maybe half postage due). This is part of why there's a problem with unwanted e-mail in the first place. Sending e-mail doesn't require storing messages and receiving e-mail does, and so sending tends to use less resources (and cost less) than receiving. (all right then, maybe more like 95% postage due)

Because SMTP is all about getting each message to its destination, it's a one-way protocol, like postal mail. There is no requirement that any information go in the other direction. Which permits senders to put false, invalid, or nonexistent return addresses on their envelopes, or even none at all.

When a message arrives via SMTP, the recipient can't be certain that it came from the sender it claims. But we can decide to use STMP to ask, by having a program send a message to that return address, and waiting for a reply before delivering the original message to a human. That's the job of a Receptionist-compatible client program. If the party at the receiving end of that confirmation request message is also running a Receptionist-compatible client program, the question will be automatically answered, with no human interaction required. And in case the other party is not using such a client program, the text included in the confirmation request message should explain how a human can properly reply - if, and only if, they really did send the original message.

By putting just a little more "intelligence" in the programs we use to send and pick up our e-mail, we can enable those programs to do a little more communicating with one another, automatically on our behalf - what programmers call a "handshake" - as two programs exchange information about each other.

And, once we have a two-way protocol, we're free to decide not to receive messages any more from one-way senders.

We can't realistically even guess what the junk in your in-box looks like, but most of ours seems to be from addresses which don't even exist. Never having to see that again can be quite a time-saver.

However, there are reasons why many of us do want to accept certain kinds of one-way e-mail. In essentially every case though, we can know about it in advance, and prepare for it. This is where the practice of "whitelisting" comes into play - we create a list of characteristics by which we can recognize the desirable one-way e-mail as it arrives. Then our program knows to let that e-mail through, even though it may not have accomplished the full Receptionist "handshake."

Mailing lists which one might subscribe to are a prime example. We can train our Receptionist to recognize those messages and not send confirmation request messages to them (which otherwise might have made us look pretty silly to our correspondents on those mailing lists!)