Doug,
I don't see how your problems, other than 1, are in scope for SSP.
Can you explain why they are, without recourse to any acronyms and
in a sentence or two each?
S.
Douglas Otis wrote:
This explores a range of possible policy and auxiliary records and label
scenarios as a general
On Aug 2, 2006, at 4:35 AM, Stephen Farrell wrote:
Can you explain why they are, without recourse to any acronyms and
in a sentence or two each?
For the most part, Problem 1 together with Solution A is currently
being discussed, but this should not be seen as a forgone
conclusion.
Douglas Otis wrote:
On Jul 31, 2006, at 12:26 PM, Dave Crocker wrote:
I would like to see a scenario described that explains exactly what
problem needs to be detected and why it is a compelling, immediate
requirement.
I agree 100% but:
=
Problem 1: Spoofs of the 2822.From
Dave Crocker wrote:
Tony Hansen wrote:
Dave Crocker wrote:
Alas, it was pointed out to me that SSP does indeed have a requirement for a
lookup even when the message is signed. This is when there is so-called
third-party signing. (I believe this means when the domain in the
On Tuesday 01 August 2006 10:56, Michael Thomas wrote:
Dave Crocker wrote:
Tony Hansen wrote:
Dave Crocker wrote:
Alas, it was pointed out to me that SSP does indeed have a requirement
for a lookup even when the message is signed. This is when there is
so-called third-party signing. (I
Scott Kitterman wrote:
2) C sends message on A's behalf using C's identity.
What does using C's identity mean?
3) B would like to know if C's signature has any relationship to A.
You mean things like uses the same ISP, operates in the same city, uses the
same operating system?
This list
Scott Kitterman wrote:
On Tuesday 01 August 2006 10:56, Michael Thomas wrote:
Dave Crocker wrote:
Tony Hansen wrote:
Dave Crocker wrote:
Alas, it was pointed out to me that SSP does indeed have a requirement
for a lookup even when the message is signed. This is when
I'm not sure if this needs pointing out but...
Scenario 1:
1) A sends to B with a missing or broken DKIM signature
2) B would like to know whether that is an acceptable state of
affairs.
And, equally important, A requires a mechanism for advertising to B (and
all the other B's) whether
And, equally important, A requires a mechanism for advertising to B
(and all the other B's) whether that is an acceptable state of
affairs.
Given the sensitivity over the Policy vs Practices issue the above
could be made less quarrelsome by stating it thus:
A requires a mechanism for
Scenario 3a:
1) A is a popular phishing target and prefers to suffer message
rejections for messages that don't carry a valid signature by A (or a
designated third party) than to have messages that are unsigned or
signed by other parties delivered.
2) C sends message on A's behalf using C's
John Levine wrote:
Scenario 3a:
1) A is a popular phishing target and prefers to suffer message
rejections for messages that don't carry a valid signature by A (or a
designated third party) than to have messages that are unsigned or
signed by other parties delivered.
2) C sends message on A's
Stephen Farrell wrote:
John Levine wrote:
Scenario 3a:
1) A is a popular phishing target and prefers to suffer message
rejections for messages that don't carry a valid signature by A (or a
designated third party) than to have messages that are unsigned or
signed by other parties delivered.
2) the scenarios themselves should focus on a situation in which a
reciever is faced with. The requirements should flow from those
scenarios.
Don't forget about domain owner's though. They may have requirements as
well and it is they whom we must convince that SSP is worth adopting.
These
I *think* he was trying to differentiate between:
- A says that he signs everything, and,
- A says that he signs everything and if A's sig is missing/bad A
would like verifiers to drop/kill/whatever the message.
I've no idea if that 2nd one ought be a requirement for ssp, but I do
see
On Tue, 01 Aug 2006 17:39:58 +0100 Stephen Farrell
[EMAIL PROTECTED] wrote:
John Levine wrote:
Scenario 3a:
1) A is a popular phishing target and prefers to suffer message
rejections for messages that don't carry a valid signature by A (or a
designated third party) than to have messages
Scott Kitterman wrote:
On Tue, 01 Aug 2006 17:39:58 +0100 Stephen Farrell
[EMAIL PROTECTED] wrote:
John Levine wrote:
Scenario 3a:
1) A is a popular phishing target and prefers to suffer message
rejections for messages that don't carry a valid signature by A (or a
designated third
Doug,
Maybe its just late in the evening here, but a mail that starts with
a list of 16 new, old, borrowed, and blue, acronyms is not IMO a way
to make what you want to say easier to understand.
I'll read it again in the morning though, maybe it'll seem worth it
then;-)
S.
Douglas Otis wrote:
I guess I had been making the assumption that an SSP query is only
necessary on a verification failure. Some of the conversations seem to
suggest that an SSP query will be needed regardless of the success of
the verify. Is that the case at all? The uncommon case? The common
case?
Mark.
Mark Delany wrote:
I guess I had been making the assumption that an SSP query is only
necessary on a verification failure. Some of the conversations seem to
suggest that an SSP query will be needed regardless of the success of
the verify. Is that the case at all? The uncommon case? The
I guess I had been making the assumption that an SSP query is only
necessary on a verification failure. Some of the conversations seem to
suggest that an SSP query will be needed regardless of the success of
the verify. Is that the case at all? The uncommon case? The common
case?
Currently,
Dave Crocker wrote:
Alas, it was pointed out to me that SSP does indeed have a requirement for a
lookup even when the message is signed. This is when there is so-called
third-party signing. (I believe this means when the domain in the
rfc2822.From
does not make the DKIM d= domain.)
I
Tony Hansen wrote:
Dave Crocker wrote:
Alas, it was pointed out to me that SSP does indeed have a requirement for a
lookup even when the message is signed. This is when there is so-called
third-party signing. (I believe this means when the domain in the
rfc2822.From
does not make the
On Jul 31, 2006, at 12:26 PM, Dave Crocker wrote:
I would like to see a scenario described that explains exactly what
problem needs to be detected and why it is a compelling, immediate
requirement.
=
Problem 1: Spoofs of the 2822.From email-address(es) common with
various
23 matches
Mail list logo
