On Mon, 2006-09-11 at 22:07 -0400, Hector Santos wrote: > ----- Original Message ----- > From: "Douglas Otis" <[EMAIL PROTECTED]> > > >> - Inconsistent results. > > > > Either the signature is valid or it is not. This does not depend > > upon policy > > ... > > Can you be a bit more specific about what do you mean by > > inconsistent results? > > I was referring to the "Dark Secret" model that Mr. Falk and Mr. Akins > was thinking about such as: > > Result = DKIM-BASE + REPUTATION > > This has the potential to be different depending on which receiver and its > non-standard reputation layer. Also DKIM-BASE mandates a: > > Ignore Failure as it was never signed > > so therefore, this model can only apply to a GOOD CITIZEN model. All > failures are ignored including the most obvious of DKIM domain abuse, > direct or indirect.
DKIM Reputation lists, due a potentially devastating impact and related replay problems, may be just a list of known identities rather than the classical spam reputation lists. Nevertheless such lists still offer protections from spoofing. As such DKIM might be viewed as the Okay Citizen model. DKIM identifies senders, improves reporting, and filtering, but does not prevent spam. Done right, DKIM can be the best thing since sliced pizza. > >> - Fake it to you make it. > > > > An assured email-address comparing with a retained email-address can > > provide comprehensive protections from spoofing. Again, this > > protection does not depend upon email-address policy. > > Doug, you keep introducing something that is NOT part of the current > model everyone is considering. Even then, you are ignoring the > failures too (i.e, when the retained email addresses "Address Book" > does not exist or you are dealing with an anonymous sender). Reputation is not part of the model either, yet it will be used. Compartmentalizing a design effort does not need to ignore how results might be used. In this case, perhaps the retained annotation strategy is the only way DKIM truly offers protection. The assured/retained email-address comparison (ARC) annotation is not much different that going to a web site that offers HTTPS security with valid Certs and a lock-icon. Without an ARC annotation, not trusting the message should be a typical reaction. Not every web page must use HTTPS with a valid Cert, and not every email must obtain ARC annotations for security to be retained. People simply need to act accordingly. > >> - 3rd party signatures > > > > When a signature can be associated with the email-address, this email- > > address can be annotated. Here policy can offer requisite email- > > address associations. If not, then no annotations and no resulting > > issues either. > > Again, same answer. I am lost. Again, what is the problem? > >> - Receivers requiring to support multiple "batteries." > > > > The MUA already has an address-book. No batteries required. > > It does? What if its not populated? The recipient may not be able to see functional links, attachments, or pictures either. The address-book is already commonly part of a security strategy. It is fairly common to see senders request recipients to add them to the address-book for this very reason. If they also want ARCA annotations, add them to the address-book. > And if it was, are you going to sure your address box with others? Huh? Do you mean third-party lists? > And whose MUA are you going to support? Any that handle standard interfaces. > Your's? Outlook? How about the others? As they said in the movie the Graduate... Plugins. : ) > Again, you are not dealing correctly with the #1 abuse - anonymous > senders at the HOSTING level. What do you mean? Any transactional email likely starts with a visit to a web site. In addition to asking for details related to the recipient, also ask for a picture or phrase so the recipient can later recognize your initial message. When they do, they can safely add this to their address-book. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
