Clearly the rfc we have now is highly interoperable at the nuts and bolts
software level.
[My opinions here is towards this statement and not the person who
made it.]
If it is meant that if ADSP was followed, then I would agree, we are
closer to closing the software based loopholes. OTOH, if ADSP is
ignored as it never existed, then DKIM-BASE is pretty straight forward.
But not when we integrating the RFcs, I have a hard time agreeing with
this. IMO, we have pretty clear conflictive technical implementation
guidelines, otherwise we would not be in this confused state that
seems to leave one with a "don't know what to do, wait and see" status
asking us to wait yet another 1+ years beyond the 3-4 already done.
For an integrated mail system, the SMTP developer and LIST SERVER
developer are in conflict in regards to the forwarding issue. Even
under the same brand of software, there is an design issue with the
SMTP software supporting ADSP being ignored by the List Server
software. Its not 'integrated software' logical.
On the domain side, domains have no clear solutions for what policy to
use. We don't have enough representation of all markets here. Discard
is pretty clear for one group regardless of how small another group
would thing that is. "all" is not very clear for any group, yet one
list group is desperately trying to make it viable. And even those
domains who wish to use "discard" are quickly finding out they will
not be protected against legacy spoofs and anonymous signers by the
purported "Good Guy" resigner market we have no general and wide
adoption method to find that out.
Even when we remove POLICY and replace it with reputation, we still
have the open question if a forwarder/remailer SHOULD|MUST follow
domain reputation public query information. The same SMTP/LIST
SERVER conflict still exist here even with REPUTATION models.
So there is no straight forward protocol and solid foundation other
than DKIM-BASE. All we have is a pretty clear mechanism for signing
machines but its value is questionable with no protected layer. IMV,
we are in a confused or better stated, COMA state, looking or waiting
for some mystical reawaken hope to occur or kick in.
--
Hector Santos
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html