Slashdot Mirror
Revising the Internet Email Infrastructure
Lauren Weinstein writes "People For Internet Responsibility (PFIR) today released a white paper aimed at starting discussion and work to fundamentally revamp Internet e-mail systems to control spam, forgeries, and a range of other problems, while empowering e-mail users rather than ISPs." Excellent start.
So, how long has IPV6 been out? How much of the net is converted?
Sure, ISPs can block PITS from unsavory PCAs, but what stops spammers from creating new, bogus PCAs as needed? If there are only a few "recognized" PCAs, doesn't this tend to concentrate power into a relatively small set of entities?
Roving Web-Teleoperated Robot
...it lives and dies by the efficacy of the CAs. If the CAs suck, then the credentials they send with email mean nothing.
I like the idea, but I wonder which sort of orgs are going to be their "PCAs"? ISPs pretty much allow any comer onto their network, so giving all users a cert wouldn't stop people from making temporary accounts for spam.
Perhaps the ease with which MTAs could cut off CAs (like cutting off domains) would help give incentive to ISPs (or whoever is the PCA) to crack down on their customer base, but that strategy is only marginally successful today. Why would creds make this strategy any better?
Perhaps MTAs would be harder to config as open relays, because authn is required. But what percent of spam comes through open relays? If it's a big percentage, then this may help.
Has anyone analyzed this scenario? I'd like to hear some informed thoughts on what sort of email regime we could expect if this were implemented.
I disagree, migrating from SMTP would not be THAT difficult. Give it a 3 year phase in or whatever, and people WILL change.
Would you change your e-mail system if it eliminated SPAM? Thats what I thought.
Now... Its just too bad that this is being done by People For Internet Responsibility (PFIR). Can't a real organization tackle this? Wouldn't something like this have a much better chance for success if a standards board were doing the white paper? Who is going to implement a suggestion by PFIR. Really.
Oh well...
Instead of proposing yet another certificate authority scheme (which is PITA to use), why not just charge for email.
A nickel an email will surely slow down spam. Maybe the money could go to some Internet Infrastructure fund or something.
well. free software might have no fbi backdoor ?
Credibility of idea has been lost due to usage of the word "empower".
I dunno -- when I read the paper, one big group of candidates that came to mind as potential PCAs are those very same end-user ISPs.
That is, when you sign up for dialup, or broadband, or whatever services your ISP provides, you'd get access to their mail server, *including* Pits certified by that ISP for any messages you send via their mailservers (given that you authenticate with them, something POP3 and IMAP already support, right?). It certainly keeps a fair amount of control and influence in the hands of that ISP, but it doesn't *preclude* alternatives, and it WOULD make it easier for those ISPs to follow good/friendly practices.
That way, any other ISP/mail provider who is willing to receive emails from *YOUR* ISP would deliver your mail. Should your ISP get a reputation for harboring spammers or other miscreants, any given mail provider can choose to simply reject your ISP as a valid certifier (or subscribe to a RBL-equivalent watchdogging the various PCAs, perhaps).
Obviously an ISP as your (or one of) your PCAs wouldn't be for everyone. Obviously there'd be a bit of a setup challenge, as far as getting various ISPs and other mail providers to recognize each other as valid PCAs. But those aren't insurmountable problems.
In fact, it sounds a lot like the SSL certification system (probably no coincidence). Hierarchical PCAs would certainly be one way to organize the solution...
Xentax
You shouldn't verb words.
1. Blacklists already exist. Since they are optional, the problem still exists. Non-solution.
2. Anyone (ANYONE) can setup a smtp server. How long it remains up depends on a lot of factors, but that basic fact is why spammers exist and why there are servers for spammers to use/exploit.
3. If one could dictate how smtp servers are configured, then no more open relays. spam dies. But we can't, so spam lives.
A radical stance is required to change. Many say SMTP is here to stay. Oh, remember the little UUCP thingy? When did they stop saying "UUCP is here to stay" and why?
Anything is possible given time and money.
It is great that folks are taking this issue more seriously but how is improving the protocol for sending email going to deter spam? This seems analogous to discouraging annoying speech by changing languages.
On a fundamental level. Economics drives SPAM. People send it because they are making money. The most efficient way to stop SPAM is probably just to render it unprofitable somehow.
Developing a new solution is usually the best way to fix technical problems. But this is really a social/economic problem. New protocols, hardware, and software can make the environment less hospitable to SPAM but I doubt they will be an effective use of resources.
The best way to solve email problems is buy having the email hosted on the users server that sent the email. The email would essentially be a link to the users server with the option of opening it. If spammers had to host and maitain the traffic of incoming users they would crumble.
If I look at the GnuPG AUTHORS file, I count exactly ten (10) people who have contributed to the code outside of people doing text translations.
Exactly how many people coded PGP? Do you even know? Can you say it was *less than or equal to 10?* is 10 "lots" in your view?
Your point would be valid if it were not for the now-well-known fact that most opensource projects *do* have a core development team of only a few people - as discussed in the recent Mozilla Roadmap.
I submit my belief that GnuPG is authored by *less* people than PGP, and by your own theory, given that more eyes *see* the code, though less people actually *touch* it, it would be *more* secure than the closed-source PGP.
Personally, I like the PGP encryption idea.
is one based on peer-maintained and user-maintained trust. I have written the outlines for such an approach.
.@.
From their webpage:
A key aspect of the Tripoli environment is the concept of a third-party certified, encrypted authentication token that would be cryptographically linked with every e-mail message. Within the Tripoli architecture, this token is referred to by the acronym "PIT" (Payload Identity Token, henceforth referred to as "Pit") and is at the core of Tripoli.
It is anticipated that all Pits considered acceptable by the vast majority of all Tripoli-compliant software user would be digitally signed by one or more designated, trustworthy, third-pary authorities who would be delegated the power to certify the validity of identity and other relevant information within Pits.
This doesn't add anything that S/MIME or PGP singed mail doesn't alrady do. And it will fail for the same reasons, putting the public key infrastructure in place is prohibitive.
It worked for https at the expense of creating the VeriSign tax, but the number of https enabled websites are few compared to the number of people using e-mail.
Ofcourse, if we bend over and hand over our e-mail to VeriSign we might finally de-throne Bill as the richest guy around...
The "SMTP Service Extension for Secure SMTP over TLS" (STARTTLS for short) defined by RFC 2487 already provides the technical framework for Tripoli. And is today supported by Sendmail, Exchange, Postfix, Exim, etc.
It normally runs over TCP port 25, the initial connection is normal SMTP, then the STARTTLS directive begins a TLS-encrypted session. STARTTLS can be configured to only accept mail sent with a trusted certificate, or to allow anyone to connect - it is compatible with existing SMTP.
The one additional item in the Tripoli proposal is the use of a trusted third party to validate certificates. Great if this can be made to work, though current experiences with PKI make me doubtful of a truly Public Infrastructure. But STARTTLS can certainly work amongst smaller private user groups.
One current hurdle preventing wholesale adoption is that few ISPs support STARTTLS. Not a problem for people running their own mail servers, though even they would want secondary servers to support STARTTLS. But if the core ISPs started using STARTTLS, they could mutually authenticate each other. Initially all mail could be accepted, but later on unauthenticated mail could be filtered more rigorously.
Andrew Yeomans
I think these ideas are on the right track in that they acknowledge the largest fault with the current email system to be lack of control over accounts by the owner of the accounts. However, the hazy ideas that are hinted at as solutions are not the right idea. They are overburdensome to implement, and I can still think of plenty of ways around them.
As for getting people to begin moving to a new system, it will need to be more than just certificate additions and user controlled filters. It will need to be something that end users can immediately understand as "this is better and easier". With the given proposals, people will have no incentive to change. that attitude will be, "Sure, I'm told the new thingy is better, but I'd rather just deal with the spam than have to deal with something new that I dont understand." End users mostly have the attitude of, "If i do nothing, I can still get my emails. If I change to something new, I might break something and be without my daily communications".
That will be where the big hurdle is.
Because obviously, you never make mistakes.
It is entirely possible that my code contains bugs. However, I wrote it with an awareness of modern attack methods, which cannot be said of a certain commonly used ssl library; further, my code does exactly what I need it to do, and no more. ASCII armor, ASN encoding, and other features are sometimes useful, but I don't need them; by not including those I cut out a range of possible bugs.
C'mon, this is an old one. It's been proven again and again that exposing crypto code to peer review is the only way to know that it's safe.
That's not true. "Many eyes" does not necessarily mean that bugs will be found -- many security holes are found years after they were introduced. A much better approach is formal proofs.
That said, see that link just above this post? My code is there; feel free to examine it.
Tarsnap: Online backups for the truly paranoid
Is e-mail address portability. So that if your mail provider gets shut down for allowing spamming, you can transfer to another with minimal disruption
Rich
This COULD work...
I think some people are forgetting an important aspect of the MTA/PCA issue:
What's to stop people from becoming their *own* "trusted authority"?
I mean, why rely on someone ELSE -- some big ISP or "Certificate Authority" (Verisign, etc) -- to ultimately say who is trustworthy TO YOU and who isn't? Why not rely on YOURSELF? (or your trusted friends?)
From my reading of the paper *anyone* could ultimately become an "authority", determining who is and who is not allowed to send email to a given person (with the "given person" in this case being oneself).
Thus I can envision a sort of "peer-to-peer" email delivery network arising from this idea wherein everyone, over time, builds their own database of "trusted sources" that would be allowed to send them email (or rather, whose email a person would be willing to accept email FROM). A private "white list" if you will.
With this approach we each only accept email from individuals/organizations that WE OURSELVES trust, -or-, optionally (on an individual by individual basis), who are trusted by others whose judgement we ourselves trust.
The email delivery "network" would thus reduce to everyone/anyone participating in the delivery/authentication of email, ala the old "circle of friends" approach.
You want to send me email? Fine. Then you need to either be someone I personally know (and thus someone I myself trust; i.e. a friend) or else someone who knows someone I trust (i.e. a "friend of one of my friends"). If you're not one of those types of people, then I'm not interested in receiving your email. Full stop.
Each person could configure their own levels of trust (i.e. how far removed from their own close circle of friends someone could be and still be allowed to send you email).
The spammers would end up quickly developing their own "circle of friends", sending and delivering their spam amongst themselves (and/or amongst demented individuals who liked receiving such junk) whereas the rest of us sane individuals would end up developing our own separate "trusted circle of friends" who would automatically reject any email from people they didn't trust (i.e. the spammers).
A "trusted" peer-to-peer email delivery network.
It COULD work.
Couldn't it?
Or am I missing something here??
"Fish" (David B. Trout)
Fight Spam! Join CAUCE!
http://www.c