overbroad

Where did I claim it's not a closed ecosystem?

It's starts closed and it is opened by invitation. Yep. That is exactly how it works.

If you cannot understand that approach, then that just means it's not how you think. It does not mean that the approach makes no sense or has zero utility.

Maybe a stupid analogy can be made if we pretend "Facebook" is the internet (of course it's not, but it does present a messaging system so play along for a moment). On the one hand you could make every Facebook user your "friend" and thus able them to send you messages, and then when people abused that privilege - and we know from experience some would - you could block them. On the other hand, you could only make a select number of people who you know and trust your "friends" and thus only give a select number of people the privilege to send you messages. Chances are, they won't try to sell you Viagra.

On the one hand there are times you may want to enable the entire network to be able to send you messages. On the other, there are times you may only want to allow a small subset to send you messages. Not sure about you, but I don't receive important email from all that many different people. People's social circles are only so big. There is a certain carrying capacity beyond which it becomes unmanageable.

"focus on applications instead of refining the tool"

It's true. How many times have we seen someone share their reimplementation of a FORTH like interpreter? Far fewer times than we've seen people write and share FORTH applications. Why that is, I'll leave as a question for the reader.

We know FORTH works beautifully as an small interpreter. There's no need to keep rewriting it except as an educational exercise. But would any disagree that there is a real need for more applications to be written and shared if the brilliance of FORTH is ever to be truly realized by more than a small group of people? Not necesarily to create some sort of silly "App Store" culture but just to show what can be done with the language. Proof of concept.

Maybe Apple is the new Microsoft, not Google? Maybe Apple does not have as many potential competitors i.e. virtually anyone selling ad space, to raise complaints?

How about using SDL? There are some LISP's that enable easy interfaces to any C library.

Spammers destroyed an open email system that relies on a centrally controlled DNS. Probably because they were among the only ones who learned how email works. We never made the effort to teach the population at large, preferring instead to let email be centralized via "email providers". And now, after decades of spam, we still have people who argue it is the best, or even the only, way to do things.

Spammers did not destroy the protocol or well-designed email servers and clients.

"Very few people should run their own email server"

That mindset is why we have a problem, in my opinion. We have actively tried to prevent people from learning.

The history of block lists is a history of the failure of the "email provider" (i.e. "very few people should run email servers") idea. Of course, anti-spam is a career for some people, so "failure" is relative. They've succeeded in trying to exert control over a common internet capability, for profit.

The internet began as peer-to-peer. There was no "DNS". And there were no "email providers". Everyone had a responsibility to learn how to use the network and the basic services it could provide e.g. messaging. Then some people got some bright ideas about how to make money. "Spammers" were not the first ones.

Enjoy that spam in you inbox. It is the product of ignorance.

What they're doing is making a very dodgey assumption. They might stop a few hundred potential spammers but they also stop millions of people who could potentially be using email more effiently and reliably (and Spam Free) by sending and/or receiving mail directly between their machines.

Email could be even more decentralized than it already is in practice. This could potentially make spam far more difficult.

Reading that quote (from SpamHaus?) two things come to mind:

1. We are entrusting the rules on our mail delivery to someone who begins sentences with "Very many" and lacks the attention to detail to spell "reasonable" correctly. Make of that what you will.

2. The "problem" is not the existence of "bad email servers" on dynamic IP's, it is the lack of "good email servers" on dynamic IP's. Why the heck aren't the millions of people on dynamic IP's using this capability? Answer: They do not know it exists.

To "replace email", we do not necessarily need to fundamentally change anything about how email works. What we need to do, perhaps, is replace the people controlling it and instruct "good" people how it works. As it stands, in general, the only folks who understand how email works are a. email providers (e.g. ISP's), b. spammers and c. spam fighters.

If the vast majority of email sent directly to recipients from dynamic IP's was low volume and noncommercial, the "bad apples" would be overshadowed by the good ones. And so would the anti-spam zealots be overshadowed by reasonable people who just want to communicate with each other (not necessarily trying to sell ED treatments to the whole of humanity).

Education is the way forward. People arguing against any sort of consumer education on something so basic as internet messaging are an interesting spectacle to behold. Their attitude should fuel the fire of anyone working on this "dangerous idea" of "replacing email". You know who you are.

"cargo-cult". That's the term I was looking for. Monkey see, monkey do. Code monkey mimicry.

If thinking for yourself is "arrogance", then we need more "arrogant" people involved in web design.

It's not the "API" that is the method of providing and restricting access. It's the IP address. Any reasonably smart user can figure out the "API". They do not need a lengthy manual. A few examples, mere hints, is all that is needed.

Ha. I've had the same thoughts many times. Never thought anyone else felt this way.

At some stage, people started to get weird ideas about URL schemes (aka "API's") like it's some sort of marketing thing. API keys. WTF? Imagine if early Google was required to get an "API key" for every site they crawled. Who came up with this silly idea of "API keys"?

In the 90's, I remember decipering URL schemes in order to do crawling long before anyone used the term "API's" to describe URL's. They are usually quite predictable, since almost every website used the same software. And they're even more predictable today. Crwaling got easier. Hmmm, I wonder why.

I also remember how most URL's used to be non-descriptive. Not true anyomre. Google has changed everything. Sites _want_ to be crawled now. But funnily enough they think they can make money from it. Heh, good luck with that.

If you want to charge money, then put the data behind a password and a paywall. And watch traffic plummet.

Gotta love that Spamhaus logic. Spammers use cheap dynamic IP's therefore anyone with a cheap dynamic IP that sends an email is a spammer.

Is it cheaper for you to get a static IP from a VPS than from your ISP?

If Alice and Bob agree to run their own SMTP daemons, closed to the public and not necessarily on port 25, and they each agree to put the other on their "whitelist", how is this functionally different from the current third party controlled system? Answer: 1. Immediate delivery, assuming Bob and Alice keep their machines online. 2. No spam. 3. No third parties exerting control over their mail. No idiosyncratic delivery policies.

I'm afraid there's no need to convince any provider of anything. At this point, Alice and Bob are sending and receiving email without the need for any third party "email provider".

Functionally blacklists and whitelists are the same. They both have the same goal. But they are not the same in their effect. Blacklisting an entire netblock to stop one bad IP address affects many IP addresses who do not need to be blocked. Whitelisting a single known IP address does not have that side effect. For Alice and Bob, handling their own messages may be a desired option. Of course, not everyone may follow Alice and Bob's example. But who cares? The population using email is enormous and diverse. The point is that if someone wants a better solution than what "email providers" offer, she can get it.

I wish we could get these anti-spam zealots to apply the same effort to stopping junk postal mail. The history of direct mail is interesting and perhaps instructive. It has been kept alive by those who do the delivery (cf. those who do the sending). I have sometimes wondered if the same might be true for email.

If your emplyer knows its recipients (e.g. business partners) and can coordinate with them to run an SMTP service for recieving and sending messages on a different port, would that solve the problem?

While I understand your sentiment, I respectfully disagree that it does not matter if it's a smart idea. Because if it is not a smart idea then that means we can do better. One of the projects I'm working on solves the "closed ecosystem" problem. The use of the term "closed ecosystem" is ironic because it seems to me that the "open" nature of email receiving (not sending) is what leads to the spam problem. In other words, I do not see the problem as the fact that people can send mass quantities of junk email. I see the problem as the fact that daemons accept and deliver mail from anyone. (And then resort to blacklisting.) What if the system was "closed" by default and instead a sender would contact the receiving SMTP daemon directly (no internediary) and would first need either a means of authentication (i.e. he has been pre-approved) or a way to have his sending address revieved and then receive permission to send. Right now you can see someting like this within a domain. For example, one gmail user might be able to send to another gmail user, directly, as they are both able to authenticate. They both have accounts (private accounts, not some RBL, DKIM or other scheme managed by an interloper) and these accounts can be checked. But if one gmail user wants to send to some non-gmail address, the non-gmail recipient has no knowledge of the sender in the form of an account against which he can authenticate. There's no privity between sender and receiver. Instead third party schemes are used. Such as blocklists for sending.

Consider the idea of running a mailserver than only accepts mail from a predetermined set of sending addresses. What would be the chances of receiving junk mail?

I guess the civil system (private lawsuits) is failing to protect intellectual property interests? Who holds those interests? The taxpayer? The government? Business entities?

Why not give the grants to businesses who are trying to protect their IP? Or to ones that are seeking to create IP and register it?

Supposedly, as the article states, this sort of capital allocation is supposed to forward the goal of promoting creativity.

But I'm not sure people will cease to be creative simply because others won't be prosecuted for alleged IP violations. But maybe they won't make as much money? Perhaps a clearer goal, instead of "protecting creativity", could be stated, such as "protecting revenue streams of businesses that produce and register IP (via fees paid to government)." As we've seen such businesses are not always the most creative. In many cases they are just the most prolific filers for IP registrations.

Creativity existed long before the legal fiction of intellectual property.

Why Mark Pincus failed?

Or did he? How much did he make from the Zynga "failure"?

An SMTP daemon will try to send the message a certain number of times, at a certain interval, then, eventually, it will stop ("bounce"). You can configure these settings if you run your own SMTP service.

Assuming your ISP is not blocking port 25 and your internet address is not on some blacklist you can send mail directly from your machine. No need to use intermediary SMTP servers.

Is it possible that someone people might like to use their native SMTP capability for low volume noncommercial email? Does every person who sends email have some overwhelming urge to send spam? Such that we must place pseudo control over sending email, any email whether commercial or noncommercial, in the hands of "email providers"?

Good on you for running your own service.

Do you think that is a smart idea? To black list entire netblocks? I mean, can we assume that every person using EC2 for email is sending spam?

It would seem to degrade the usefulness of EC2 for anyone wanting to run their own mailserver.