[ih] Endliss misconceptions about Email reliability

[Jack Haverty]

On 1/16/24 06:59, Chet Ramey via Internet-history wrote:
> If they want to use email to communicate with customers -- and they 
> do, for
> whatever definition of customer you like -- they also want to know to 
> make
> that pay off with engagement (and, of course, donations). 

You might consider this behavior as seen by the other side -- do 
"customers" want to use email to be flooded with a firehose stream of 
marketing campaigns, political messages, requests for donations, social 
media posts, and other email they didn't ask for and don't want?

Personally, I have separate mailboxes that I use whenever I'm forced to 
provide my email address.  I receive hundreds of messages per day on 
those addresses, and every few weeks I just delete them all. More 
precisely, my computer downloads them all and deletes them.  I wonder if 
the sender thinks I read them.

For my "real" mailboxes, I do also get unwanted email but it's usually 
easy to recognize and I simply tag it as spam.   If it happens 
frequently enough, I set up an automatic filter to do so. I also avoid 
using "unsubscribe" buttons or links, since that seems to sometimes 
simply confirm that an actual human has read the message, tagging my 
email address as a more valuable target for marketing.

People I know have similar strategies to try to handle their incoming 
email and "separate the wheat from the chaff".   It would be interesting 
to know what kind of effect such behavior has on the metrics of "success 
of email campaigns", and whether or not anti-spam techniques actually 
reduce spam, or perhaps instead increase it because more emails still 
result in more success.   In the datagram world of the Internet, if your 
packet gets lost, you simply send it again.  The same philosophy might 
be (is?) used in email.

Collectively we call this "spam", and IMHO it's been getting worse over 
the years, triggering a flurry of "anti-spam" and "privacy" efforts, 
which have unfortunate side-effects affecting reliability of email.  
Coupled with the effects of misinformation and disinformation, the SNR 
(Signal/Noise Ratio) of The Internet has been dropping.  IMHO.

Curiously, a similar effect has been occurring in telephony, with the 
advent of "robocalls", and various efforts to control them. Like email, 
there is essentially no marginal cost to making another phone call.  My 
bill for my phone is the same, no matter how much I use it.

For the historians...

Back in the early days of email (early 1970s), I was involved in a 
research project with JCR Licklider at MIT, exploring the potential of 
the then-new Arpanet.   Since Lick was a psychologist by training, we 
explored some of the non-technical aspects of networking, and in 
particular "human-human communication" such as email.   One of the 
conclusions was that it would be important to have some kind of 
"negative feedback" to prevent abuse of the technology - i.e., some 
"cost" of sending email to suppress the gluttony fostered by "all you 
can eat" designs.

We explored the concept of "stamps" for email, analogous to the postal 
system, as well as other concepts like "registered" or "priority" mail, 
with appropriately different costs.  Costs didn't have to be monetary - 
simple constraints such as a limit on the number of messages per hour, 
day, or week could also provide the negative feedback of backpressure.

Sadly, such mechanisms were not popular, and deferred for some future 
version of email.   Fifty years later, sometimes I wonder if all of us 
sitting at our desktops, laptops, or smart devices are the actual users 
of The Internet.  Or are we the products whose attention is being sold 
over The Internet to the legions of companies and organizations that 
think of us as their customers?

Jack Haverty

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20240116/1cc4efdb/attachment.asc>