Damon:
SSP does not help me decide which bank is real.
Again, I know who my bank is. If I get a message from BoA or a message
from the First Mountain Trust of Namibia, I believe I would not have
any trouble distinguishing between the two.
I don't expect burglars to put WARNING: BURGLARY IN
Wietse Venema wrote:
What is the relevance of this for the current effort? I have nothing
against an SSP that says what mail if any a domain signs or sends.
Like many, I would use that to throw away some mail. But it would be
a mistake to position SSP as the solution for email phishing.
Jim Fenton wrote:
Wietse Venema wrote:
What is the relevance of this for the current effort? I have nothing
against an SSP that says what mail if any a domain signs or sends.
Like many, I would use that to throw away some mail. But it would be
a mistake to position SSP as the solution for
Dave Crocker wrote:
Right. So let's explore what current problems specific functions in SSP
will mitigate.
Folks who are proponents of particular SSP features should document
specific threats and specific SSP feature(s) that will mitigate them.
An essential part of such exercise is to
Michael Thomas wrote:
Any sort of analysis needs to keep in mind that although SSP thwarts
a relatively narrow set of attacks in and of itself, it could well
be useful in conjunction with various phishing filtering heuristics,
reputation, and the like which are all outside of the scope
Stephen Farrell wrote:
An essential part of such exercise is to explain why the mitigation is
strategic. That is, why will it not be easy for attackers to work
around the SSP mechanism and achieve equivalent attack success.
Modulo look-alike domains I guess? (There's text in 4868, 4.2.1
Dave Crocker wrote:
Right. So let's explore what current problems specific functions in SSP
will mitigate.
Folks who are proponents of particular SSP features should document
specific threats and specific SSP feature(s) that will mitigate them.
I think that'd be useful.
Of course,
On Dec 14, 2007, at 9:32 AM, Stephen Farrell wrote:
Dave Crocker wrote:
Right. So let's explore what current problems specific functions
in SSP
will mitigate.
Folks who are proponents of particular SSP features should document
specific threats and specific SSP feature(s) that will
Steve Atkins wrote:
On Dec 14, 2007, at 9:32 AM, Stephen Farrell wrote:
Dave Crocker wrote:
Right. So let's explore what current problems specific functions in SSP
will mitigate.
Folks who are proponents of particular SSP features should document
specific threats and specific SSP
On Dec 14, 2007, at 10:10 AM, Michael Thomas wrote:
Steve Atkins wrote:
On Dec 14, 2007, at 9:32 AM, Stephen Farrell wrote:
Modulo look-alike domains I guess? (There's text in 4868, 4.2.1
about
that btw.) I don't think anything in SSP can mitigate that threat.
In that instance the
An essential part of such exercise is to explain why the mitigation is
strategic. That is, why will it not be easy for attackers to work
around the SSP mechanism and achieve equivalent attack success.
Modulo look-alike domains I guess?
Depending on the threat, there's all sorts of likely
Wietse Venema wrote:
Jim Fenton:
(1) It changes SSP from being a protocol that governs the error
condition of an optional protocol to being a protocol that governs
*every* email received by *every* MTA.
Application of SSP to only messages containing broken signatures has
*never* been proposed
I don't think SSP is hostile to the DKIM deployment, but helps its
deployment because it will at least provide some avenue of protection
for domains and receivers who don't wish to get into 3rd Party Trust
Service dependencies where there is no standard definition and
absolutely no
Wietse Venema wrote:
I don't think SSP is hostile to the DKIM deployment, but helps its
deployment because it will at least provide some avenue of protection
for domains and receivers who don't wish to get into 3rd Party Trust
Service dependencies where there is no standard definition and
14 matches
Mail list logo