On Sat, 2006-09-09 at 19:05 -0400, Hector Santos wrote: > Doug, > > Not everyone will be able to produce a cross the board solution. Only the > "Microsofts" and the likes will have the capacity to address a consistent > solution across their applications.
Browser and MUAs are extensible in a manner similar to MTAs. One does not need to design an entire application to add a feature. > Although we are a small company with one of the oldest and most > complete total mail design frameworks in the market, even I realize we > can't do that. Your company does not need to do anything for these extensions to be available. > We can make it work for us in an integrated fashion, but we can't > dictate our TOTAL solution will be the right TOTAL solution for > everyone else. Its unrealistic and it would be unrealistic for others > here who might feel their total solution is right for us as well. Annotating a message at the presentation layer will not make physical changes to the message. This approach will not impact applications in current use. > But what is common with all of us, is the MTA or more specifically > x822/x821 internet mail operations. Reading mail, while there is are > standards on the OFFLINE side with popular methods (POP3, IMAP), there > are a multiple MAIL ACCESS methods which you can't control, online, > proprietary, API based, gateways, etc. POP3, IMAP, and various web mail presentations are extended in the manner suggested. > For example, using us, we have the following mail access methods all > controlled using a single source backend system: These other modes of reading email will not likely warrant being extended initially, although scripts can often be invoked that are able to apply the algorithm suggested. If the features becomes popular, someone may bake them into less popular interfaces. > And a bunch of 3rd party mail readers. It would be a mistaken to believe > that x822 is the common format between all of them (for the internet > clients, yes) but not necessary the rest. Covering IMAP, POP3, and web mail presentations offers protection for a a high percentage of users. > The buck really stops at the server side if we really want this to work. A > centralize source. Your nor my MUA needs should not stop the progress with > implementing DKIM-BASE/SSP solutions at the MTA. Conversely, efforts at the MTA should not jeopardize the integrity of email delivery. Don't break the signature. Ensure a false positive rate does not increase. A highly selective policy at the MTA should be okay. Overly broad and aggressive policies will likely cause a problem. > In my opinion, if you have a MUA application in mind, you should > concentrate on how it will communicate with the server side. The interface at the server and the message does not change. Only email-addresses that are retained and assured valid by DKIM can offer safe annotations. Exploring policies that increase the coverage of DKIM's validations, and that offer increased selectivity is where the WG should be focused. Providing greater coverage with less administration will improve the DKIM user experience and better support its deployment. And yes, DKIM in conjunction with these other efforts can substantially prevent phishing. Just don't try to do this with blocking alone. My worry is that John might be right and no blocking should be attempted. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
