Hector Santos wrote:
Clearly, this is what happens when you have 2+ years of work
commandeered in less than 2 weeks (admittedly a thing of beauty in the
art of Mastering Chaos) with essentially a Find/Replace string
stripped down document (IMO borderline unethical) where you end up
with conflictive semantics all over the place.
Clearly, the attempt was to remove all MTA verifiers logic for
filtering DKIM mail with the only explicit semantics provided for a
MUA entity.
But you also need to ask, why even have an SSP or ASP "skeleton"
document? We already have the model of ideas in RFC 4871 and RFC 5016.
At this point, I would vote for a total SSP/ASP abandonment rather
than risk the email world to such questionable late minute changes
without thinking much about the consequences.
With respect to the process by which we got to ssp-02:
Eric and I (with most of the hard work done by Eric, of course) worked
on a stripped-down version of SSP in late December and early January
that we thought was closer to what working group consensus was at the
time. We shared this early draft with the Chairs. I was still
concerned about making such a sweeping change without specific direction
from the WG, so on January 25, I sent out a message "A proposal for
restructuring SSP" in order to socialize the idea.
One of the responses I received was from John Levine, who was editing
the ASP draft with a number of other people operating outside the
working group. We exchanged drafts and found that there were a lot of
similarities, and (with John's permission) incorporated some of the
language from that early ASP draft into SSP. As I remember, Appendix A
is almost entirely from the ASP draft.
I do think that we took the appropriate steps before introducing what is
more than an incremental change from the previous draft.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html