[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trusted agency




On 10/18/11 12:20 AM, SM wrote:

 At 19:56 17-10-2011, Douglas Otis wrote:
> Agreed as well. What is needed is a light weight method to avoid
> abusive sources with a glimmer of hope it might actually work. We
> defend our services dynamically from

 Taking people off the web removes a source of abuse. Keep in mind
 that without these people, you won't be paid. :-)

Allowing endless abuse of SMTP seems destine to cause its destruction, as happy eyeballs look elsewhere. Happy eyeballs pay our salaries not those want to abuse the inbox. Adoption of 65K IPv4 Internet (prefix) equivalents, rapidly growing another 6 fold fairly soon, will decimate all reactive blocking strategies. Sanctuary will not be found by only accepting IPv4 connections either.

> Neither SPF nor DKIM properly defend domains. IP address
> authorization and signatures omitting senders and intended
> recipients against actually authenticating the accountable domain
> is what is lacking. These two schemes largely support
> white-listing domains considered "too big to block" and glaringly
> lack a practical means to defend smaller domains or at inhibiting
> spam. Email is in the ditch.

 SPF and DKIM, like any other scheme, is not some holy grail that will
 solve all the email problems. All schemes largely support "too big
 to block". That is how consumerism works.

You are confusing consumerism with how an oligarchy works, right? Currently, the Internet represents an open market where receivers should be allowed to ask who is piping sewage into their home.

SPF doesn't care who should be held accountable, nor does DKIM care whether a message is being abusively replayed and by whom or whether it has been modified to offer deceptive presentations despite its promise in the introduction it could be safely deployed without changing clients. Neither SPF nor DKIM offer the means to authenticate an entity that can be held accountable for abuse. SPF will soon horribly break, so that will go away on its own.

> In the face of IPv6, address authorizations schemes become
> increasingly problematic and disruptive. Email needs to learn
> from social networks.

 Social networks is where a lot of spam come from but we cannot call
 it that.

When a user is able to limit those with which they exchange messages (a buddy list), there isn't any spam problem. Even when bad actors return under a different name, they still don't make the list.

Admittedly, security with all the dancing fruit within these proprietary services is a nightmare, where cleaning up SMTP so it can play its proper role seems far more appropriate, productive and safe.

> Have each develop their own authenticated "buddy" list as an
> overlay to what individual users might adopt. Perhaps Apples
> example explained in RFC6281, might provide a method

 See web of trust.

A web of trust is not possible without actually authenticating the _accountable_ entity or domain. There are some options that could reduce the related overhead without inventing new protocols.

> compete with social networks, a light weight method to authenticate
> outbound MTAs is needed, or eventually email will be supplanted by
> various proprietary services. Many

 From draft-ietf-marid-csv-csa-02:

 "Internet operation has typically required no public mechanism for
 announcing restriction or permission of particular hosts to operate
 clients or servers for particular services on behalf of particular
 domains. What is missing is an open, interoperable means by which a
 trusted agency can announce authorization for a host to operate a
 service."

 Which trusted agency should it be?

John Leslie has already answered this fairly well. With the way the transition to IPv6 is likely to play out, any effort to utilize an IP address can only be done on a transient basis. The underlying entity should still be confirmed by way of something like a kerberos ticket. In that view, a new type of service could emerge that offers tickets for various activities within the framework defined by RFC6281.

-Doug