Oh, I didn't know there was a requirement for one to have IMPLEMENTED
and DEPLOYED proposed protocols before one can have any sort of
engineering insight into problems and their resolutions? I'm sure that
is not what you mean.
Sure, it helps, but keep in mind DKIM itself was engineered with little
to no DEPLOYMENT experiences by the very authors themselves for a very
long time. Many folks here were in the same position, including us
(Santronics Software) only finally implemented and deployed when there
was a sign of a payoff with an Author Domain protocol work product in
the WG. Nonetheless, not having deployment experiences should not mean
we don't know what we are talking about and I surely hope that doesn't
become the next mantra to participate in the IETF WG process.
And consider also, that many of the current problems with DKIM and the
lack of a payoff were 100% predictable and foretold by many here,
including myself, including Mr. Otis. Recall the "battery required"
talk? While there as direct experience for me with the early Visanet
market, this was discussed even during MARID. It was well foreseen as
the wrong path for DKIM to use without an AUTHOR DOMAIN layer to it. It
was a early rejected proposal to use a Reputation (GOOD) layer. Remember
CSV/DNA? Its no surprise that DMARC is now following author domain
concepts offered by SSP, DSAP and ADSP.
Remember, DKIM had SSP built-in. It was removed. IMV, that was when all
the second guessing began with DKIM and in my view, it was clearly the
wrong thing to do when SPF was still coming on with strong definitive
handling (rejection) semantics which DKIM failed to establish.
Practically everyone was looking for a strong rejection based protocol
for mail.
Remember that DKIM's original charter stated Mailing List was to be
looked at as an after-thought to the main consideration with policy.
Mailing list WAS NOT the prime consideration - it was written in the
charter as a secondary consideration. The problem is that we had to
now cater to the 3rd party channels. A valid concern but one well known
to be fraught with major issues with middle-ware design concepts. But
we allowed this side of the design community and market to trump all
others higher value private transaction concerns. It was "too small" to
consider. That was a mistake. And remember, there were proposals,
ideas to allow the middle ware to work, but then we had to forget about
author domain policies to allow for a futuristic "battery requires" 3rd
party reputation/trust resigner market to work.
DKIM Deployment's guide conflicts on this very concept - support ADSP,
yet allow for middle ware to ignore ADSP. Nuts! Guarantee Author Domain
Protocol killer if you can't get the middle-ware folks to support
honoring Author Domain policies - all known long ago without or little
deployment. I was proposing in DSAP that both can co-exist. But no, the
reputation folks did not want Author Domain policies to dictate over
middle-ware signatures. That little last minute was stipulated in the
SSP Functional Specs RFC and it KILLED IT!! Why bother now.
So it is what it is today; a very little to zero DKIM payoff. Systems
signing with some marketing value, and perhaps processing/verifying but
there is no expectation that it has any handling value. DKIM is
currently a big waste of processing time. Super high waste and the
bigger you are, the more waste you have and more you absorb as well.
Will DMARC change that? Only if you get the small folks - the MAJORITY
of the network, involved. That is why SPF took off - it was the entire
industry that jumped on board to support a REJECTION based protocol that
was so drastically needed at the time. For DKIM, it really came a day
late and a dollar short and when SSP was removed, well, it only made SPF
that more stronger.
The IRONY in the DKIM story is that the same folks that didn't like SPF,
came to realize that it needed SPF to help DKIM. Now you have the same
group of authors doing all three. That could be good but they really do
need to begin listening (and reading the mail) of the Author Domain
advocates. So much time wasted.
To me, it may be too late. The only way to jump start all this again is
to come up with real strong technical sales/advertising/discussions for
the support of real Domain Handling policies - that is when the
WORTH/PAYOFF factor and new processing ideas will come. In the mean
time, it (DMARC) is just more waste with yet another TXT-based record
lookup!
SMTP
SPF EHLO/HELO optional
SPF MAIL FROM
SMTP DATA/PAYLOAD
DKIM
ADSP
VBR
and now we add DMARC?
DMARC
That is basically what? 5-8 TXT Lookups? Ridiculous!
Perhaps the group of folks putting all these things together should have
a IETF lunch meeting and start thinking about better consolidating all
this TXT-based worthless lookup into some single cohesive author domain
with 3rd party/mail list support solution.
Just look at the TXT vs unique/new RR type debates. Another TXT-based in
DMARC will not well. Too much. We need a single author domain protocol
consolidation that is extendible, flexible to support a wide range of
ADMD declarations. It will support SPF, VBR and DKIM domain policy
layered protection ideas.
I think Murry can write it and get wide support (wide to me is small to
large, no exceptions) if done correctly.
--
HLS
On 6/23/2013 7:28 AM, Franck Martin wrote:
+1
Michael, if you don't want to deploy, that's your prerogative, but don't
claim supposed problems are blockers when you don't have any experience of
such deployment...
On Jun 23, 2013, at 1:06 AM, Murray S. Kucherawy
<superuser(_at_)gmail(_dot_)com<mailto:superuser(_at_)gmail(_dot_)com>> wrote:
On Sat, Jun 22, 2013 at 9:49 PM, Michael Deutschmann
<michael(_at_)talamasca(_dot_)ocis(_dot_)net<mailto:michael(_at_)talamasca(_dot_)ocis(_dot_)net>>
wrote:
(I have deployed DKIM alone senderside, but that's just to keep in
practice in case someone invents an accessory protocol that's actually
sane. Allowing me to declare that all mail bearing my RFC821 MAIL FROM:
without a corresponding signature is bogus while saying nothing about
that which merely bears my RFC822 From: would be a good start.)
If that's the magic you seek, I propose writing it up as an I-D and doing
some practical interoperability experiments, and see if it takes off.
It's easy to lob "you should've done it this way" grenades without actually
putting any energy behind it other than a critical missive here and there.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html