Spam is not Email's fault, but the mere result of its success/importance, which has only been possible due to its interoperability, which in turn facilitates spam.
It would be the same if we had all been using - say- XMPP for the last 20 years.
It would be the same if we had all been using - say- XMPP for the last 20 years.
There were from a few dozens to a few hundreds of hosts on the entire network at this time. Most were educational institutions, meaning a campus sysadmin could run herd over users (if students) or refer to deans / departments (faculty). This from the 1970s through the early 1990s, at which point things began evolving rapidly.
Transacting email itself wasn't all that expensive, though for many sites it was batched via uucp or similar mechanisms.
It's always going to be a bit of an awkward fit to today's Internet where you can trust that any and every exposed service will face some attempt at abuse.
If the friends and family address gets spam, offer a way to create and distribute a new address.
For business it is tricker as you want anyone to email you. Here regular antispam measure are probably best.
On the other hand people might want to keep pseudonymous and throwaway mails. Nearly the exact same warnings apply here as they would have applied to those that chose Google as a mail provider and now complain about lacking support and account closure. A largely self-inflicted problem. Don't continue this naivete...
Spam is annoying, but not a threat. Phishing is to a large degree. That needs user training, people stopping to pay ransoms and sensible IT policies for corporations.
That said I can count on my fingers and toes the number of spam messages (via hijacked accounts) that have reached my Facebook Messenger/Instagram inboxes and have received zero spam in several years on Snapchat.
Walled gardens have many downsides, but there are upsides as well.
So yes, most walled gardens' two-step approach makes the spam more civilized, but they don't eliminate it.
That said, I only communicate with a couple dozen close friends on snapchat so perhaps a more active user will get spam.
What's not arguable is that spam is email's problem.
What responses to my quite off-the-cuff though apparently resonating comment has (mostly) failed to recognise though is that spam is a problem not only for email users but across the spectrum for operators, administrators, senders, application designers, and a whole host of others. The fact, volume, and consequences of spam have a tremendous set of knock-on effects which are hard to express with any degree of coherence and sufficiency.
Which system gets it right and could email be fixed?
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.