Barry Leiba wrote:
> --------------------------
> 4. Discussion of the future of the working group
>
> Two charter items not yet done:
> 3. Collect data on the deployment, interoperability, and
> effectiveness of the Author Domain Signing Practices protocol
> (RFC 5617), and determine if/when it's ready to advance on the
> standards track. Update it at Proposed Standard, advance it to
> Draft Standard, deprecate it, or determine another disposition,
> as appropriate.
> 4. Taking into account the data collected in (2) and (3), update
> the overview and deployment/operations documents. These are
> considered living documents, and should be updated periodically,
> as we have more real-world experience.
>
> - Is there energy and desire to do this?
Not for these two items. Barry, the issue is never about convincing
POLICY advocates. This "collect data" was perceived as yet another
way to further put off completing a chartered work product. If we
had a true champion as the editor of ADSP, no question, it would of
been a lively active working document and WG discussion with sincere
updated proposal design changes because of all the high interest and
input provided to try to make POLICY work. POLICY was not provided
"an equal opportunity" chance to be a) worked on, b) by a highly
motivated believer of his work, and c) was there simply no interest by
the editor to do anything about it to move it forward short of just
saying it broken, by design, therefore Don't use it, 3rd party signers
can ignore it and tried to get it removed from the charter.
It never had a chance.
We know what POLICY can offer immediate domain security. We spent many
man-hours on it with two document products, RFC for SSP Requirements
and RFC for Threat Analysis which were essentially ignored. I'm sure
any SMTP vendors in the mail business really don't need additional
proof of concept to see a how new method effectively "legalizing" a
new higher bar expectation for mail transactions which can help
provide a new "legal" dissemination for legacy operations to a very
high zero false positive degree - with no questions asked.
So what is the real question we wish answered with "Collect Data?"
Who uses ADSP?
Thats easy, systems who support it and all existing APIs support it.
The problem is the ADSP editor has promoted the idea ADSP is broken
and promotes the idea that 3rd party signers (like mailing list) do
not need to support it. So within the WG, there will be little
incentive to support an idea not even the author supports.
I'm pretty confident having a true champion behind POLICY and we will
we see a different positive situation occur for POLICY. I believe if
that was to happen, the collect data would flow like a flood as DKIM
systems are encouraged not discouraged from supporting it.
> - Should we recharter instead for different work?
If we can get a renewed focus for DKIM POLICY with a different editor.
Yes.
> - Should we close the working group?
I don't see any further useful outcome with a status quo. So yes, if
we can not get a new set of supporting engineering eyes for POLICY.
> Are there objections to this? Does anyone want to convince us that
> there's interest and energy to keep it open and do more work?
Barry, I'm sure you know has always been a high interest in a
DKIM+POLICY layer. Its in the charter and its diminishing focus was
not one due to primarily to technical merits but simply put we had the
wrong person on it. It was clear and obvious conflict of interest and
incompatible issue which should of been addressed long ago by the
IETF. POLICY had no change with Levine behind. There was never a
desire to address all the comments provided and the fact is there was
never any updates to fix all the clear ambiguity expressed by so many.
So lets get to the real issue. What you are really asking is about the
future of POLICY, not the WG.
I would like to see a WG whether as a continuation of this IETF-DKIM
list or a new IETF-DKIM-POLICY WG to finally give us a chance to
complete a solid DKIM+POLICY security protocol for DKIM without all
the intentional anti-policy WG disruptive interference seen over the
years.
I personally believe that if the IETF can help give POLICY a WG chance
to be designed right, I think you will see some real positive
adoption, marketing and confidence for DKIM. But who knows if that is
true or not. We don't but you (speaking in general) can not denied
there has always been a strong interest for a DKIM POLICY layer - its
even a chartered item.
But we just never really had a chance.
My concern is sincere. I still have hope DKIM can help tremendously in
the ongoing email security fight against domain fraud. What I don't
want to see come to a reality is the "Cry Wolf" comments such as one I
received recently from a customer testing and exploring our new
DKIM+POLICY implementation:
"The initial version for non list mail worked fine for me for a
period of time
and then I started regularly getting DKIM=FAIL in the smtptrace
log so I have
not looked at again for some months."
- Customer comment on using our new DKIM implementation
Do we really want DKIM to get into a common situation where lacking a
protective layer for domain DKIM signed mail becomes ignored as
wasted overhead and bandwidth?
I hope not.
I perfectly understand the DKIM-REPUTATION model promotes the idea
that only VALID mail (Good Mail, white listing model) should be
considered when its signed by a trusted source. Everything else is
basically "undefined" by DKIM.
Fine, I won't debate the GOOD MAIL Trusted Source model. The job was
well done by the WG promoters of this model. VBR seems to be
promising as an open protocol.
But maybe the POLICY promoters can be given a chance to address a
layer that helps protect the unsecured abusive "undefined" block
ignored by REPUTATION.
Thanks
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
