Sender-initiated contact is an absolute necessity for a near-universal communication protocol. If you don't allow for it, then you require that all forms of social introduction be supported in the protocol itself, or you turn introduction protocols into a vehicle for spam.
It's also worth noting that not all spam is unsolicited--people give uninformed consent all the time. (This is part of the reason why legal remedies to spam have failed: it is actually very hard to give a robust, concrete definition to spam).
Email is not entirely sender-initiated. The sender must know the email address of the receiver, and that step -- getting to know the email address of the receiver -- is not supported in the protocol itself.
In other words, email is not "near-universal" and entirely open, because the receiver must give you his email address, by means of which he is consenting to receive your emails.
---
In any protocol where the message stayed at the sender's server and could be fetched by an authorized potential receiver (such as the one I linked to, with variations introduced by my imagination) there could be ways to quickly "get" one's email address, like today we do by reading the address itself.
For example, instead of showing a written email address in his website, one could show a link to third-party identification/message-request authority which would be in charge of filtering these things and letting the potential receiver choose what he would want to receive. This introduces the problem of spam again, but at least it is outside of the main protocol, and the protocol could live without it.
Another solution, now thinking specifically about the "streams" (see my previous link) protocol, is that each person willing to accept email from new people could open public streams -- and yes, they would be subjected to spam, but since the receiver would have absolute control of that stream and what does its server does with the messages, it could enforce a strict format (for example, every message could only be "let me talk to you, add my stream at ____"), and it could change its address from time to time. The customizability of the thing would be its main feature, since no spammer machine would be able to go into all these personal standards.
Also, having a public communication channel that is restricted to messages that say "I want to talk to you" is going to totally inhibit spammer behavior. No spammer will spend time trying to get people to talk to him. It will filter out machines and let only people.
In any way, the social introduction, as you called it, can exist, and does not have to be supported by the protocol (although, like in my second example, it could be done though the protocol). Supporting it as a feature of the protocol would only make it more automatable and easy for spammers.
---
I've just came up with these ideas while writing, so there are probably a lot of problems, but the main point was that there is always a pre-protocol social introduction, and that can be bad or good depending on how things work. Probably with email it was good to just give your address to everybody on the internet some years ago, but now just by writing it in a post you're going to be massively spammed.
It's also worth noting that not all spam is unsolicited--people give uninformed consent all the time. (This is part of the reason why legal remedies to spam have failed: it is actually very hard to give a robust, concrete definition to spam).