Douglas Otis wrote:
This draft goes to the opposite extreme of the ASP draft and increases
the restrictions for "all" compliance as well. This draft indicates
_ALL_ messages are to include a signature with an i= parameter matches
that of an identity within the From header. This is not the defined use
for RFC 4871.
The ASP approach creates fewer corner cases. At least with the ASP
draft, any risk of misuse remains within the control of a domain to
rectify.
IMHO, unless the SSP draft is changed to comply with RFC 4871, the WG
should consider adopting the ASP draft instead.
First, I don't agree that SSP did not comply with RFC 4871.
Second, I for one am tired of this stuff going on in this WG.
For all intent and purposes this ASP Adaptation is essentially the same
document, the same copy of SSP with essentially the term Originator
changed to Author. It has a removal of verifier semantics and 3rd party
issues, and alters the SSP DKIM=ALL definition with a flawed concept of
ASP DKIM=ALL having no failure potential. It has the same issues as the
SSP document. It offers no solutions to key issues discussed over the years.
In addition, bulk mailers, which this ASP documents attempts to focus
on, are going to experience a negative exploitation by bad people using
the suggested DKIM=ALL policy with fake signatures.
ASP::DKIM=DISCARDABLE is 100% the same as SSP DKIM=STRICT so I don't
even know why it was even considered as "new."
ASP::DKIM=ALL attempts to enforce the idea that failure is an acceptable
conclusion, even if comes with an unexpected 3rd party signatures.
If ASP is adopted or SSP-02 with its ASP twist is adopted, it is going
to have a negative effect on receivers and domains in the general case.
It envision when receivers see no payoff and are going to mostly reduce
DKIM overhead by ignoring it completely.
I don't see any more hope in this WG for a policy technology that is
going to help DKIM signers. It appears Jim/Eric has succumbed to the
pressure of a limited group of self-interest consortium that surely do
not represent the entire community of domains and mail receivers.
--
Sincerely
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