Undesired solicitations are going to be a factor on any sufficiently widely-used communications network. There are ways to reduce the impact, but most come down to some measure of real costs (as with postal mail), gatekeepers (as with, say broadcast media --- there's plenty of solicitation but it's at least curated, and no, that doesn't mean I can stand it myself), or systems with strong effective authentication and reputation capabilities, which would include most social networks.
It's trivial to address spam on trivial systems --- those which are small, centralised, and tightly controlled. It's difficult to do so on nontrivial systems --- those which are large, decentralised, and loosely controlled.
Email is very much the latter. It also lacks costs (sending has exceedingly low marginal cost), and has very poor authentication / identity assertion, and reputational capabilities. All of this is baked into SMTP at pretty low levels, and the various bolt-on kludges to address this (SPF, DKIM, DMARC, and anything else that I'm not yet aware of) are at best only partially effective, and rather fragile and fiddly. Among the reasons large monopoly email services are so effective and useful is that they "see" the spam problem at a global level, across hundreds of millions to billions of accounts. My statistical background tells me that this is almost certainly overkill, and that even services with only a few hundreds or thousands of widely-shared known addresses (something easily accomplished by honeypots) would achieve much of their effectiveness.[1]
Another huge problem for email is that there's a lot of loose coupling between end-user clients and servers, especially for desktop-based (non-Web or mobile App) systems. Contrast with social media or webmail in which a person's flagging of an item as spam or abuse is instantly registered by the system, which has full awareness of where the item originated and what other activity has come from that account (or if sufficiently sophisticated, known clusters of accounts) recently. In the case of email, the end-user client, the receiving server, the sending or relaying server, and the original injection point(s) might well be three or four entirely independent systems, for which there's no through chain of identity and often asynchronous hand-offs meaning that flagging actions are noted only long after the message was initially accepted for delivery.
That flexibility was useful early in the history of SMTP's development. It's an Achilles heel now.
One possible reform would be for sender to spool mail until it's been accepted for delivery. This would complicate sending (especially at high volumes, not necessarily a Bad Thing), but would mean that the determination of whether or not a message was spam, or behavioural assessments (e.g., Sender A has requested delivery to 1,000 local addresses, many of which don't exist and/or are honeypots) might permit a presumption of spam before the actual acceptance of the message.
All of which would raise costs to spammers and make use of botnets for delivery far less reliable in that those sending hosts would be identified as spammers before many messages could actually be transacted, assuming that white-hat recipients share reputation data regarding sending sources.
Another practice generally is to have a varying level of service provided based on the level of familiarity, trust, and/or value associated with specific senders. Given weak authentication this is not especially robust, but it would again make simple-minded email blast spamming highly ineffective. This practice has been fairly widely adopted in some forms by corporate domains which require specific whitelisting of authorised senders as a general rule. Implementations last I was aware tended to be ad hoc and kludgey. It's an annoying but reasonably effective method.
________________________________
Notes:
1. The law of large numbers and spam's reliance on broadcast distribution largely account for this. A small number of individual spammers hitting effectively all known email addresses account for a huge proportion of spam. Knocking a single such operation offline can drop global spam. This is a 2008 story in which a single provider accounted for 75% of all spam: <http://voices.washingtonpost.com/securityfix/2008/11/major_s...> . Smaller systems (< 100m accounts, say) might tend to miss more sophisticated targeted attacks and lag in responding to these --- phishing, spear phishing, and APT attempts against specific accounts. I'm not sure if this is a trade-off or not, though I suspect any sufficiently highly-place PEP (politically exposed persons) would attract such attention, and that this risk is not especially scale-responsive. This is also somewhat tangential to spam in the sense of indiscriminate mass mailings, though both are serious concerns for email integrity.