[ietf-dkim] draft-ietf-dkim-ssp-02.txt and ASP

[Hector Santos]

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