On 10/17/11 4:51 AM, John C Klensin 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 questionable sources as a method to
prioritize the rest. Not grey listing in the classic sense, but no less
of a PITA and an extremely complex system still constantly being gamed.
--On Sunday, October 16, 2011 22:57 -0700 "Murray S. Kucherawy"
Maybe a shorter way to put that last paragraph is that if we
agree that reasonably timely delivery of mail is a Good
Thing, then I think we have many other problems to tackle
before we turn our attention to greylisting.
Agree here too.
And even more strongly agree if "delivery of all legitimate mail
without forcing senders to use a small number of senders with
bilateral arrangements" is added to the list.
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.
In the face of IPv6, address authorizations schemes become increasingly
problematic and disruptive. Email needs to learn from social networks.
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 to include separate services that
perform authentication, and then simply hand out SMTP tickets that are
good for some period of time.
It is interesting that services like twitter's ad revenue "unique"
criteria gives them an incentive to cancel abusive accounts. Two
seconds later, they may reappear under a different name, but that is
okay as now they must then beg for attention. For email to 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 domains are not aware of incoming connection failure
rates due to loads not seen in SMTP logs. Incoming messages might not
be blocked, but may never get through the growing volume of noise.
Please add this new service to your "buddy" list.
I understand failure to respond to your complaints in a timely manner
may cause my domain to be removed from your "buddy" list based on
protocol X authentication methods.