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.
Spam is totally email’s fault. They should have had disposable email addresses built into the protocol so they would be easy to support. Then when an address starts getting spam, run the spam filter more aggressively on emails to that address or block it entirely. Or they should have included PoW so it takes a little bit of CPU time to send an email (wouldn’t do anything about botnets, but not every spammer has a botnet handy.) I can’t think of any other ideas off the top of my head, but it’s absolutely true that there are ways that email could have been designed to be less of a problem
Ultimately e-mail is a relic of a time when there was some level of trust (however small) among Internet users.
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.
DKIM, SPF, DMARC... old tech and it just got reactivated recently. Will take a time to spread.
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.
Less email as proof of work than having a known network address (this was when the hosts file was distributed manually, and bang paths were common) was proof of trust.
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.
Isn’t it just how you handle mailboxes. Let fred@domain.com accept and receive email at any fred+X@domain.com address with ability to block any specific address getting spam.
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.
I suppose I agree for the narrower claim that a protocol which allows anyone to message anyone is going to inevitably have spam.
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.
You don't get spam on Snapchat? I think you might define it differently than I do. Since those walled gardens have a verification step before allowing sending messages, spam on those platforms consists of "friend requests" from unknown people. If one is foolish enough to accept one of those, the more traditional spam message soon follows.
So yes, most walled gardens' two-step approach makes the spam more civilized, but they don't eliminate it.
Not a single one! I suppose I occasionally see friend requests from unknown users, but they don't actually convey a message or achieve any possible advertising goal.
That said, I only communicate with a couple dozen close friends on snapchat so perhaps a more active user will get spam.
Whether spam is or isn't email's fault, or a consequence of its architectural naivete, is arguable.
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.
Most WA users I know get it, it's been a point of discussion in several group chats. But not enough you need spam filters, the need for which is the biggest problem with email because of false positives (I scan thru my junk mail folders weekly when I remember and find legitimate messages every time).
Interesting. It goes to show how varied people’s experience can be. I get zero spam on my seven year old Postfix server as long as I have greylisting enabled (my only anti-spam measure) while I get the occasional spam message on Whatsapp (that I only use for work purposes on my work phone since 2020).
Heh, you can tell how much I definitely don’t use it. I only recall when someone tried to get me to use mine they showed me a username (nickname?) and a QR code. So I must have registered a number at some point.
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.
It would be the same if we had all been using - say- XMPP for the last 20 years.