J D Falk wrote:
The protocol is extensible. Let's gain experience with this basic
protocol and let experience teach us where extensions will be useful.
I think this is the only possible way forward. Maybe it'll turn out
that Hector and Doug are both right, but we won't know until we try it.
(I seem to recall saying something similar about SPF, long ago -- and
look how much we've learned since then!)
And what was learned that was not already stated during the SPF
development process? I don't seem to recall your input in the SPF
groups or in MARID and the same concerns that one may claim today were
already stated during the WGs discussions.
And the same concerns with SPF, which for me regarding RELAXD
provisions, that were predictable back them, I will restated it here
for this SSP-02 A.K.A ASP, the same exact issues will occur.
For all intent and purposes:
ASP::DKIM=UNKNOWN ----> SPF NEUTRAL
ASP::DKIM=ALL ----> SPF SOFTFAIL
ASP::DKIM=DISCARDABLE ----> SPF FAIL
You guys did absolutely nothing new, and simply reinvented the same
issues that already preexisted.
If you think ASP::DKIM=ALL will exonerate BULK MAILERS, and HOTELS,
well, you heard it here, the failures with ASP:DKIM=ALL will not
tolerated for long.
As it was already said, the beauty of the SSP=STRICT or ASP=DISCARDABLE,
the same thing really, is that it was path independent unlike the more
desirable SPF=FAIL policy, but problematic in multi-hop issues.
With anything less, there is NO benefit.
But at the very least with SSP-00, SSP-01, you had a partial solution
for 3rd party signers.
By eliminating this, you made the problem worst for DKIM, not better.
--
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