Hector Santos wrote:
a DKIM-BASE only environment is going to create major
problems for veriifiers
There would be several cases (obvious if I'm right, but I'd
be interested if I miss something):
1: 1st party signature from a known author, that's still good.
2: 3rd party signature from a known good relay, maybe better
than heuristical timestamp line analysis (?)
3: signature from unknown parties or no signature is as before
(without DKIM)
The lost case (without SSP) is an opportunity to reject mails
without 1st party signature claiming to be from authors who
normally sign everything (or let their ISPs do this for them).
Dave's proposal wasn't to remove SSP from the picture, but to
move the info with "delegations" from SSP to subdomains of the
author's domain. Avoiding the threat explained by Jim.
I'm not hot about it, but it's a real threat, minimally it has
to be documented. Like Scott proposed, 4408 also "solves" the
similar "shared host" issue by documenting it. And those who
really don't get it can read an I-D explaining op=auth. That
strategy could be also okay for SSP:
Just explain that "delegations" to a party not knowing about
this honour could be a very bad idea (if that party signs all
submissions down to the lowest grades of authentication).
A nice example I've seen in RFC 3958 (S-NAPTR): the client
(for DKIM: the verifier) would ask the server (the designated
signer), if it's really supposed to sign on behalf of the
author, or if that's only a bad idea of the author. Whatever
you (collectively) do, don't reinvent 3958 or 4408, use them
if that makes sense.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html