postfix-users March 2011 archive
Main Archive Page > Month Archives  > postfix-users archives
postfix-users: Re: The future of SMTP ?

Re: The future of SMTP ?

From: Eric S. Johansson <esj_at_nospam>
Date: Mon Mar 14 2011 - 13:47:04 GMT
To: postfix-users@postfix.org

On 3/13/2011 9:37 AM, Dennis Carr wrote:
>
> So the problem is not with SMTP, it's with the spammers. Only thing we can do
> is block them. I really, REALLY wish there was more we could do so we can
> stop them - but the only thing we can do to stop them is to make it cost more
> than it's worth, and the only way I can admittedly come up with would be
> pretty unethical. .
>

Dennis, normally I would ignore these rehashes of the same old "why is SMTP
broken" discussions because I've lost too much time in them over the past
decade. Your comment about making cost more than it's worth seemed like an
opportunity to give a brief brain dump of ways of increasing opportunity cost to
spammers.

There are a couple of ethical ways of increasing opportunity cost. The two that
I am most familiar with are identity and sender pays systems. Identity systems
identify either the server or the individual using some form of cryptographic
fingerprint or signature to uniquely identify that message source and be able to
enable exclusion of that message source should it generates spam. The
opportunity cost of an identity system comes from the time it takes to get an
ID and how long it can be used before it is labeled as a spammer. I don't like
this system because it enables corporations or governments to silence speech.

The example I like to give is that the e-mail addresses of activists on the
issue of Tibet could find their ability to communicate turned off should the
Chinese government declare their identity to be sources of spam. Also, Monsanto
could do the same thing to agricultural activists. To top it all off, it's very
expensive, you need to ask questions of fungibility of IDs between multiple
registrars or the social cost of one big registrar. one fun thing about this
model is what happens when a really big spammer organization decides to play a
shell game with multiple registrar organizations that they own and mix in their
own spammer IDs with legitimate userids that they have issued. If you think
turning spammer off is bad now, try turning off an identity registrar that is
owned by spammer.

Sender pays has always been controversial because, quite frankly of the "geeks
bad at math" syndrome. It appears very simple at the surface but in reality, has
some very cool properties underneath but to get from the surface to the very
cool takes a bit of work and a different way of thinking. one very interesting
property about sender pays systems is that they improve the environment for
everybody, not just the users. when you add to a sender pay system a reputation
database (who sends good mail and how much), sender pay systems become much more
powerful as you can now apply variable costs to a sender as you get to know them
(better reputation).

I rejected a monetary based sender pays for a proof of work system because of
fungibility of currency, susceptibility to denial of service attacks on the
currency issuers, and problems with a detectable double spending.

Proof of work systems have a series of advantages and non-obvious disadvantages.
They are distributed, can be incrementally adopted, and simultaneously put a
burden on the spammer while reducing the cost of identifying and delivering
messages from good sources. In other words, it changes the focus from punitive,
filtering out bad to selecting/enabling good message delivery.

Most of the bad arguments against proof of work sender pays comes from the paper
is titled something like "proof of work doesn't work". They used a couple of
strawmen to discredit the concept while ignoring the real properties. One of the
arguments was that the amortized cost of a proof of work postage stamp becomes
infinitesimally small adds almost no cost to the spammers operation. they
didn't address the issue that generating proof of work stamps slows the rate of
sending mail and that the property that increases the opportunity cost the spammer.

The second argument they used was costs on a legitimate sender and they can pull
it ignore the work I published which was the early parts of my reputation model
I added to proof of work systems. You don't need to send a stamped to anyone you
know i.e. previously delivered e-mail to. That lets you send messages at almost
the same rate if you are truly legitimate mail source. Starting up is painful
for very small number of days but, there are also a variety of ways of getting
around the startup problem as you seed your reputation database.

Obviously this is just scratching the surface of what you can do with proof of
work systems and reputation databases. the plus side is that they are
completely distributed, cannot be interfered with by corporations or
governments, once spammers start using proof of work, it slows the rate of
production and makes things better for everybody. It can be used to identify low
frequency emitters (zombies that send small number of messages). The solution
can be incrementally adopted and is beneficial beyond what a content filter
provides to the early adopters.

The minus side is that in order to understand this, you do need to learn new
things and be willing to work through some simple mathematical models. I know
that sounds insulting and I apologize but this has been consistently the
sticking point in getting the concept across. People who sit down and Go through
the models are the ones that have given me the best argument against the system.
The same people have been able to help find solutions to these problems and make
the models better.

I will leave you with this. The models work, they have been vetted by a number
of people who are smarter than I am. there is a proof of concept implementation
available (twopenny blue) the source code is on launch pad so you can play with
it to your hearts content. It integrates nicely with postfix, has a couple of
ugly problems with an occasional Unicode conversion error and one improperly
handled race condition in SQL (I really hate SQL). I haven't been able to do
anything with the code for couple of years but it is there, I've been living
with it for the past five odd years and it makes my life far easier than any
content filter ever has except maybe google's anti-Spam filter.

This is just a quick summary of my knowledge and experience on sender pays
systems and ways of increasing opportunity costs to spammers in a globally
beneficial fashion. if someone wishes to play with twopenny blue, feel free to
contact me directly.

--- eric