----- Original Message -----
From: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Saturday, September 09, 2006 2:27 PM
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION
I would call forcing phishers to switch from
exact domains to look-alikes progress.
+1.
SSP as a signature policy failure detection concept, it will offer an
optimal migration path with backward compatibility with a high payoff
compared to a non-SSP DKIM-base only environment where there is no incentive
for bad-actors to adapt or change their current ways.
When there is no incentive to adapt, the receiver market is left in limbo
with little to no benefits in checking for DKIM-BASE mail.
My proposal is a natural consideration for a SMTP vendor in how to best
implement DKIM-BASE with SSP to offer protection for DKIM while still
supporting legacy systems.
A receiver can only find out if a sender is a LEGACY system or a new DKIM
based system by checking for domain signing attributes.
Its a YES or NO question.
NO - Legacy Operations
YES - Non-Legacy DKIM operations
This is why I say in a DKIM-BASE only environment, the #1 loophole is for
bad actors to do nothing, simply because SMTP systems MUST still support
legacy operations.
So if we want to protect against this Legacy vs. Non-Legacy loophole, we
need a way to check for the domain status and it has to be based on the
minimum x822 header requirements. In this case, it is the x822.From header.
So SSP at the very least has to be about closing the "loopholes" that
DKIM-BASE promotes.
Anything beyond that it can not do. It will not stop phishers and it will
not stop the compliant DKIM bad guy.
But as you say, if we move them in the direction of using DKIM or moving
away from direct exploitation of domains, then that is indeed progress.
Once we close these deterministic loopholes, then the content related
HEURISTIC systems become themselves more powerful.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html