[ih] DMARC [was "Father of e-Marketing"]

[Chuq Von Rospach]

> IMHO, the simplest effective anti-spam technique is an economic one.  If
> it cost even a tiny fraction of a cent per addressee to send an email,
> I'd expect there to be a lot less spam.  There are a variety of such
> economic techniques to exert backpressure on senders, e.g., perhaps a
> 500 email per day limit on a typical "home user" account for free, with
> high-volume users paying (a lot) more.

This idea popped up at least every 18 months for over a decade, and was
seriously discussed by variou groups many times. I think there were
four, maybe five, attempts to implement something around the idea that
at least got kicked off and never went anywhere significant.

John already mentioned "An Overview of E-Postage", but I thought it
wouldn't hurt to suggest thinking about how you might actually build
and implement this kind of beast.

I was involved back in the day in three significant attempts to define
"SMTP - the Next Generation", all built around the idea that email was
going to die soon if we didn't figure out how to replace it with a
modern system. One of those, if I remember correctly, was sponsored by
IETF and organized by John.

They all ended up at some variation of "we have no idea how to get from
here to there". It's not designing a "new SMTP" that's the problem, it's
switching the universe to it.

Anyone who is old enough probably remembers vaguely when the internet
and BITNET were separate and email there was the gateway between the two
for email. And it took years to get everything to the point where that
gateway could be shut down, and there was still some serious pain
involved in doing so.

Now translate that much smaller, relatively contained, and more
centrally controlled situation to today's internet and ask yourself "how
do we convert 100% of the internet from SMTP V1 to SMTP V2?"

Short answer: there is no engineering effort that will succeed trying to
make that happen (*cough* IPv6 *cough*) and if you try to build a system
that allows SMTP V1 to interconnect, then the bad folks will just
continue using SMTP V1 and you solve nothing, unless your theoretical
gateway can magically figure out the bad guys and block them. Which, in
practice, is what's already been done with tools like DMARC but
backported into butressing SMTP, which is still humming along despite
being declared dead every year or so by someone, here were are 20+ years
since the last time I thought about how to build SMTP V2.

So effectively, while it's not perfect, we actually did implement SMTP
V2, and it actually works pretty well. it's not perfect, but do you want
to guarantee perfection in the new protocol we could theoretically
define? If so, bless you.

I'm not really sure there's anything at this point we could do with a
new SMTP that hasn't already been layered into the existing SMTP.

And the point I'm making here is this: you can't remotely start building
"economic techniques" into email without tearing it to the foundation
and building a new one from scratch, and that new one will fail because
almost nobody will want to use it unless they can get their email from
the old systems, and once you interconnect to the old systems, how do
you enforce these economic techniques? You basically can't.

So you are dealing with the problem people who really wish everyone
would leave Facebook has: everyone is already on Facebook, and people
will want to be where all the other people are, even if that other thing
we built on the shiny city on the hill is better.

This idea is an interesting one at one level, but it fails the "how do
we bell this cat" problem: there's no practical way to build this
successfully and get people migrated, and our grand kids will be running
the gateway servers and continuing to threaten to cut off those that
won't migrate Really Soon Now. And as long as the gateways run, the
problem can't be solved, even if SMTP V2 does in fact solve them for us
(which is arguable...)

Anything we could think to implement in an SMTP V2 to fix these problems
could be built on top of SMTP today,  and we have 20ish years of history
going back to Paul Vixie's MAPS work showing how that's actually
happened. The problem with "pay to send" email is that any system wants
to implement that against the rest of the net will get routed around as
a network failure by users who insist on getting email from the people
they want that have no real incentive to pay up, because their
recepients will just send it to Gmail instead to get it.




Chuq Von Rospach - http://www.chuqui.com
Email: chuqvr at gmail.com
Twitter: @chuq
Silicon Valley, California
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20190605/099356e8/attachment.htm>