Barry Leiba wrote:
Closing the working group doesn't mean that work on DKIM stops. It
just means that this particular organized piece of work has come to an
end. And I understand Hector's concern about access to MAAWG, but,
again, it's not the only place where there's discussion, and this and
the other mailing lists will continue. Many MAAWG members will still
participate in discussions outside MAAWG, and there should be a flow
of information all 'round.
Thanks for your comments.
For the record, I don't discount the endorsement value of this trade
group. The concern is not so much about access to the trade group
although that would be an issue since AFAIK there are no open forums
for this trade group participation. While that may change tomorrow,
overall, the general concern is the risky promotion that a trade group
interest becomes the primary endorsement requirement for further work
or even stop any current work and this may not represent the entire
IETF mail community interest.
Specifically, is the trade group promotion and suggestion for more
trade group incubation periods for a DKIM Policy Proof of concept.
Most people understand that the key issue is one there there is a
deployment conflict between 3rd party and 1st party DKIM signatures.
What makes it a DKIM sensitive issue is that the out of scope
Reputation motivations pushed out in scope Policy motivations. With
the last call, the out of scope reputation modeling will now become
part of the standard. By not including POLICY as part of the
standard, it makes is much harder to get POLICY back in the picture
without a new revamping of the DKIM reputation standard.
I tried to introduce practical solutions that will be not compromise
reputation, keep the door open for Policy and help promotes consistent
DKIM mail system integration with less need to revamp the standard.
The latter is the most important and I don't think we have dealt with
that.
I am not asking to change the specs that now promotes reputation, I am
asking that to make it work better we one basic idea instilled:
- 3rd party signers are not entirely unrestricted.
Since the layer for evaluation semantics for TRUST Assessment was
finally added to RFC4871bis DKIM-BASE at this late stage, it is only
logical that we add identity text regarding POLICY Assessment.
It was stated the justification for adding the trust assessment layer
semantics was because other documents already make this deployment
possible.
I firmly agree. It makes DKIM mail system integration more consistent.
However, the same can be said for POLICY which was a chartered item
and also stated in other documents, especially in the security threat
document and also in the deployment document.
So again, my interest is mainly about mail system DKIM protocol
integration consistency.
Unfortunately, while it may be comforting to know the discussions will
continue, we also know it will a very hard to get policy back into an
IETF WG standardization effort simply because it will requires
upgrading of the DKIM standard. Once we have a large market of
unrestricted signers technically legal by standards, it will be very
hard to change this highly exploitable DKIM relaxation built into the
standards.
But then again, who knows. Maybe as bigger industry gorillas begin to
endorse and add policy support such as Microsoft, the IETF will now be
forced back into the position to make POLICY a standard, just like it
happen in MARID which Microsoft finally endorsed SPF. SPF was taken
off on its own, but IETF did nothing until Microsoft came out with
their own versions.
Anyway thanks for your comments regarding the WG future.
--
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