Murray,
Thanks for your comments. The key difference today is that we have
finally achieved the long term engineering considerations of:
1) Getting domains to publish DNS policy records,
2) Receivers performing the DNS policy record lookup,
3) Receivers honoring the mail handling.
We did not have this with ADSP when ATPS was first introduced as an
extended ADSP add-on. ADSP, the DKIM WG proposed standard track item,
was in conflict with what we reestablished today as "indirect mail
flows" and the key cogs of the DKIM WG was focused on eliminating the
Author Domain Identity (ADID) from the specification and making 3rd
party Trust Signers (SDID) the key focus identity for DKIM evaluation.
ADSP was being abandoned and you help kill it by eventually
replacing it with DMARC.
If you redid ATPS as an add-on DMARC, I suspect we will have a higher
interest in its exploration. The marketing and need would be much
higher than before. It will certainly push forward our own update
efforts (Replaced ADSP with DMARC and I would like believe other mail
product and EPS vendors, including MLS developers would also would
update DMARC to support a new SDID (Signer Domain Identity) optional
parameter in the DNS policy record lookup:
DMARC = DKIM_POLICY_DMARC(ADID [,SDID])
We are already doing the lookup as a function of ADID. We established
that. Thats the difference today than yesteryears. Now we just
proposing to make it flexible for the 3rd party signature condition
when the ADID != SDID.
We also long established, which I believe all the trust advocates
agreed, that resigners are good. They are needed when the original
authenticity is lost, i.e MLM.
Will the vendors support it? Who knows? But the market is different
today and that is all I am saying, you can't judge the lack of
interest before because ADSP was being abandoned. DMARC is not being
abandoned. It now needs to be completed with that 3rd party component.
I suggest a simple update of ATPS to anchor off DMARC and see if we
will get the exploration. You will get two immediate packages to
support it. Yours and mine.
If in the mean time, you come up with something better, great. I don't
see it because it will always need to be verifiable with the 1st party
again, but now we will be able to explore all the scalability issues.
I personally don't think the the non-ESP domains will need to worry
about that. Perhaps the biggest challenge for the larger ESP is how
to best register the domains. But thats an implementation issue,
perhaps using a Web site with other business decisions such as free or
fee-based. Let the each market vendor decide that. In the mean time,
we need the 3rd party Authorization extension for DMARC.
Thanks
--
HLS
On 3/27/2015 2:59 AM, Murray S. Kucherawy wrote:
On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull
<[email protected] <mailto:[email protected]>> wrote:
Murray's point is that "proof of illegitimacy" is probably a pipe
dream, as shown by past experience with "policy frameworks".[1]
Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows
in daily use by financial institutions and in other transactional mail
flows.
Put another way, you only really know something when DMARC, DKIM, SPF,
etc. produce a passing result. (Due credit to Dave for this
observation.) All of them have false negatives with respect to
anything that's not a direct mail flow, so "fail" results don't tell
you anything conclusive if you plan to accept any sort of mail that
isn't direct. What Hector characterizes as a watering down of SPF
with the publication of RFC7208 was merely this fact put into text,
even though it's been true since RFC4408.
Footnotes:
[1] Hector is right that they haven't really been tried, but I don't
think the chance that they'll be tried in the future is high, because
the reasons they've been hard to implement in the past remain true.
I agree. And although Hector likes to ascribe considerable power and
influence to me, I'm not the one standing in the way of their
success. I would happily embrace any such solution that stood a
chance of working. I, and others, simply ask some basic questions
about scalability of such solutions, their complexity, and their
ability to be "gamed", and then they never go anywhere because there
simply aren't any good answers to those questions. Thinking I might
be wrong, and since the same people insist I am, I published RFC6541
(ATPS) as an experimental draft to try to tackle the third-party
problem, and made a free version of it available via open source.
That was over three years ago. There has been exactly one site (one
person, rather) that tried it besides me and reported back about its
effectiveness. Though Doug will shortly claim that ATPS saw no uptake
because it is "flawed", I also had a grand total of zero operators
report that they were using it in any modified form or asking me to
add this or that to it before they would deploy it to production. It
wasn't just an idea, it was a reality, but nobody came to play.
Policy and third-party solutions haven't failed because of some cabal
keeping them from seeing the light of day, unless by "cabal" you mean
"group of people who agree that this won't work."
These are hard problems, and the last thing any of us should want to
do is foist yet another blob onto the global email infrastructure that
has not been properly vetted. If an idea doesn't stand up to scrutiny
or gets no uptake, or can't even get consensus in a small working
group, what prayer does it have for success on the greater Internet?
I want to make things better, not worse.
There are those among you that disagree, I know. Does anyone have
actual data (not theory, not passion, but data) that any of the policy
or third-party solutions we've discussed before can work, work just
about everywhere, and work at scale? If the answer to that is "no"
(or, as usual, silence), then I suggest this (still!) isn't a
productive use of our precious time or energy.
-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
