John R. Levine wrote:
But this is exactly what DKIM is. You prove yourself fsvo "prove"
to the registrar who "certifies" you by virtue of placing your NS
records in the root servers instead of issuing a cert.
Registrars, as we all know, rarely check any credential beyond the
confirmation code from the credit card charge.
hmmmm, doesn't that depend on the cert being purchased? There is a
higher due diligence done for the more expensive "seal" which comes
with a higher indemnity. AFAIK, depending on your PCI level, you
can't get the "el cheapo" cert like the Turbo SSL offered by GoDaddy
because auditors will fail you.
I'm still not seeing what a cert provides that couldn't be handled by VBR
or another DKIM signature by the certifier.
+1, I think VBR can address the "wildcard" signer which may not be
desirable (by the receiver and by an 3rd party authority). But I
think you answered this in your RFC security session:
The receiver of a message with a VBR-Info header field MUST ignore
certifiers that it does not trust; otherwise, a bad actor could just
add an authority that it has set up so that it can vouch for itself.
No matter what, like everything else, there needs to be a "White List"
of VBRs that is either defined locally or via a centralized source.
The problem, unlike the browser market, is that SMTP vendors do not
have a common source to do this and even then, they may only want to
do this for selected VBR records, Author Domains and signers.
--
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