On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote:
On Thu, Apr 16, 2015 at 11:34 AM, John R Levine <[email protected]> wrote:
At least, we need to look at what non-technical costs they push onto other
parties.
Some changes have insignificant non-techincal costs and are not
controversial, e.g., adding a List-ID header for the benefit of recipients
who know how to use it. Changes that seem similar may have quite different
costs, e.g., adding a List-ID and removing subject tags, forcing recipients
to change the way they sort and organize their incoming messages.
Rolf kind of said what I'm thinking here: I agree that we need to look at
the costs. But are we willing, or not willing, to accept costs that are
not zero?
For example, asserting that all parties should have to take on zero
non-technical cost here seems like it might leave us dead in the water
before we even start. I don't have a good non-zero suggestion though,
because it's hard (or maybe even impossible) to be specific.
Murray, we don't need to go that far.
We are talking about a IETF protocol engine that has two basic flows:
ADID == SDID conditions
ADID != SDID conditions
We just need to come up with the models for this and let the market
decide.
The problem is that ATPS was short-changed as an extension to ADSP
which was being abandoned.
The APIs were ready for this. Since DMARC replaces ADSP, you need to
update RFC6541 to have it piggy back off DMARC. Since DMARC is now
being adopted to replace ADSP in the industry, you now need to make it
market ready for the 3rd party check allowing them to learn how to
scale it too.
If you want to do this IN-BAND stuff for those systems that can not do
DMARC+ATPS, that would be great and it would cover a wider market,
including the biggest one who can afford the additional changes to all
this. They can also afford to do both ATPS and IN-BAND as well if
they choose to so.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
