On Thu, 2006-09-07 at 09:59 -0400, Thomas A. Fine wrote: > Douglas Otis wrote: > > Not all messages signed by a domain are: > > - trustworthy. > > - offer valid email-addresses. > > > > These facts poses a basic problem when attempting to convey trust > > related information to a recipient by way of annotation. How else is > > DKIM to be used? > > Well, MAYBE TO PREVENT SPAM!!!! Gaaah!
DKIM can not prevent spam! > But I just really really don't get what you're getting at. DKIM is > (or should be!) essentially a transport layer solution, and you're > talking application layer. DKIM is transparent to the recipient. DKIM is unable to block messages from bad actors. DKIM does not even safely allow white-listing from large domains where there is risk of replay. There MUST be an application layer to convey which messages are offering some form of DKIM related assurance. This could be that an assured valid email-address is also contained within the address book. It could also be that a trusted domain categorically assures an email-address. Either scheme offers valuable protection from common spoofing. > So some particular application wants some mechanism whereby it > distributes levels of trust in it's email. Why wouldn't they > just add a header line to their mail that says "this mail is > extra-double-secret trusted", and then sign that line along with > everything else? The only control a domain has with respect to DKIM signing is over the use of the email-address. DKIM signing can happen at the MTA and the MUA. The only way to say "Trust this message" would be by way of the email-address or some added assertion made within the key/signature. > > Most institutions are not willing to vouch for the integrity of all > > signed messages. Once signed, a message can be replayed, thereby > > amplifying concerns of their integrity. An ability for the domain to > > vouch for only specific email-addresses offers substantial protections > > for both the domain and the recipient. > > WHAT!?!?!! WHAT!!?!?? Why would a domain sign a message if it wasn't > vouching for that message!!?"!?!?? There can be different levels of assurance a domain may wish to convey. A domain may wish to convey a high level of assurance for only specific email-addresses or messages. The other assurance levels would be this email-address is valid, or this message passed through our system. These represent distinctly different levels of assurance. > Messages can be "replayed"? How does per-user signatures help stop > that? DKIM doesn't make assurances about the intended recipient, > only about the sender. When asserting a high level of assurance, the vetting required of these messages is more stringent than that of other messages. Perhaps no links are allowed from outside domains, for example. The source might be limited to automated messages or trusted mangers. The replay risk simply makes this vetting more critical. > > This selectivity can be achieved without email-address selective > > policies. However, isolation by email-address likely conforms to most > > domain's expectations and present practices. > > Please please please give an actual real-world examle of what your > talking about, because everything I read from you sounds like > mumbo jumbo. Just one little real live situation. That's all. > Come up with that, and at least maybe I'll finally understand what > you're talking about. BigBank.com is being heavily phished. An MUA vendor wishes to offer different levels of assurances to combat phishing and to restore trust in their messages. BigBank.com is large and has many new employees, and must deal on occasion with compromised systems. BigBank.com would like to limit the risks associated with high level assurances being offered as a feature of the MUA vendor. It asks the MUA vendor to limit these assurances to only those messages from the email-address [EMAIL PROTECTED], for example. The MUA vendor allows the recipient list their trusted domains, or perhaps pre-captures a list of trustworthy domains. The next step is to determine within these large domains, what email-addresses should receive high level assurances. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
