On Sat, 2005-11-05 at 05:04 -0500, Hector Santos wrote: > Where do you get the "expose expressed desire" that a domain will even want > you to sign its messages in the first place? Does the domain have choice in > the matter?
In my view, DKIM is essentially protecting the email message transport system. For there to be hijack protection, every message should be signed by the transport domain. I think there should be three basic signatures. See: 9.4 Multiple Signatures http://www.sonic.net/~dougotis/id/draft-otis-dkim-threats-01.html#anchor25 > Even then, it does matter. You have a major threat by avoiding first time > inconsistency. With your idea, a system will need more sampling to get a > better feel. What if its one phish per system attack spread across a tens of > thousands, even a million systems? Are you now going to throw in a RAZOR > like concept into every expanding solution pool so that these participant > P2P systems can learn from each other? A phish with a look-alike domain would depend upon a reputation service to deal with that problem. A phish using exactly the same domain, but unsigned, would represent the status-quo until the phished site starts signing their messages with the broad-binding (or phished-binding) assertion. If the domain is not receiving messages from the phished domain, then any phishing attempts would not be a continuation of a prior correspondence. I remember Mike indicating that coverage does not need to be 100%. If you having not done any business with any-bank.com, it is not hard to ignore these messages. Perhaps someday, rather than just silly lock icons, there can be a box displayed that indicates the verified domain. > Why not just reject it with a 451 because of the match failure? If its a > legitimate SMTP system, his SMTP system is designed to retry. There would be a great deal of valid email that would be rejected with this logic. An email-address and a signing-domain not matching should be permitted or many things break. This mismatch will not change upon a retry. Either you reject or accept it. If you have not seen messages from a domain previously, you may want to Temp Error to see if they are using a new domain to send spam. It will not take long to appear on a reputation service. > > Your chart should not offer hostile treatment when email-addresses don't > > match the signing-domain, unless they are on a list. > > Doug, the CHART has nothing to do with with a LIST, LEARNING, ANALYSIS, > DIAGNOSTICS or BEHAVIOR of domains. The chart simply allows systems to STOP > the CRIME before it happens. You are stopping legitimate emails in your scheme. You are stopping messages where the only crime is someone using their alma mater address, or a list-server such as this one, distributing content. Frankly, the DKIM signature alone will stop far more crime when the opaque-identifier is added. The bane of the Internet is compromised systems, and the opaque-identifier will help a great deal to stop that problem. This will put an end to the millions of ignored compromised systems sending malware and spam. The opaque-identifier provides a means to automate compromised systems out of existence by reducing tracking efforts by an order of magnitude. The opaque-identifier would not expose people's identity as SSP does. The opaque-identifier would only be understood by the provider. They will understand. : ) > The chart offers a theoretical 69% (25/36) hard results with zero > false positive ACCEPT/REJECT conditions. It has 31% (11/36) states > where there is insufficient data to make a hard decision. However, in > these cases, there is nothing to prevent a system or implementation to > augment a pattern recognition learning concept of repeated failures. Sorry, but this is wrong. You are making rules that brand legitimate email as bad to claim the scheme works. This scheme does not actually stop abuse, but instead exposes email-address domains to unfair reputation. The ones that may benefit would be the mega-domains that are less likely to be unfairly treated. > Doug, you are totally mis-representing the entire idea of what SSP is > suppose to do. I'm sorry, but I can't help but feel you are doing this > intentionally. SSP will require senders to add their provider's email-address as well as their desired return address on the From header to satisfy the SSP god. Hundreds of thousands of applications will need to be rewritten to add these double From email-addresses. All of this, while confusing the heck out of everyone when nothing works as expected? > > When they are not on the list, then the reputation of the > > signature would simply be evaluated. > > There you go again, We are back to a DNA concept. DNA supports accreditation which is just _one_ form of reputation. Reputation can mean locally maintained lists, left/right black-hole lists, and of course accreditation lists. I never said anything about DNA or accreditation! > Where is the pseudo-code? What needs clarification? Making a list, checking the list? How reputation is obtained is beyond the scope of DKIM. -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
