On 4/29/2014 7:54 PM, Murray S. Kucherawy wrote:
On Tue, Apr 29, 2014 at 3:00 PM, Douglas Otis
<doug(_dot_)mtview(_at_)gmail(_dot_)com
<mailto:doug(_dot_)mtview(_at_)gmail(_dot_)com>> wrote:
There will be an effort made to better generalize the TPA expired
draft. http://tools.ietf.org/html/rfc6541 (ATPS) was hostile to
existing mailing-list services and, as such, could not be
deployed. Nor was it more suitable for high volume email
services. An effort to change From header fields will have users
guessing which field indicates who authored the message and in the
end will provide no benefit.
ATPS was deployed as part of an open source package since before it
was published. It has seen negligible use, and I suspect that's
because there has not to date been any demand for third-party signing
mechanisms of any kind.
Disagree, because you went at it half-hearted. You made it
experimental and your abstract even stated that it probably means
nothing. More importantly, Levine and Crocker didn't support the
effort, so it didn't have a chance at all.
Its call marketing just as it was done with DMARC which is less
flexible than any other policy system. If you don't champion it, it
goes nowhere.
In any case, ATPS, TPA, and its variants all run up against a
whitelisting scaling problem. I think that's the more interesting
thing to discuss.
It was already discussed. Unless you are sharing this "Whitelist" in
some centralized fashion, it won't be a persistent and consistent
protocol solution. What it will promote is targeted abuse at those
sites that do not have the same whitelist -- You ware making it so
that "Batteries Required" in order to function.
We been thru this already. We need a standard consistent and
persistent domain based solution all can apply equally and one that
you don't need to buy "Batteries" to get any payoff. Even with all
the "small use cases" belief that is being proven wrong about policy,
you guys are still in denial about policy. Everyone is telling you
guys you got it all wrong, and you still won't listen. This thing will
never be solved with a status quo.
--
HLS