Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

[Hector Santos <[e-mail]>]

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
> <[e-mail] <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 
HLS