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