[ietf-dkim] SSP = FAILURE DETECTION
dotis at mail-abuse.org
Sat Sep 9 17:55:00 PDT 2006
On Sat, 2006-09-09 at 19:05 -0400, Hector Santos wrote:
> 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
> 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
> 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
> 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
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.
More information about the ietf-dkim