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) C sends message on A's behalf using C's identity.
3) B would like to know if C's signature has any relationship to A.
4) If C's signature does not have a relationship to A, then A prefers
that the message not be accepted for delivery
This is the same as scenario 1. The message doesn't have A's
signature, B wants to know if that's OK. The set of possible C's that
we don't trust is unlimited, and I can't see any point in trying to
enumerate them.
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 the difference (and the fact that there're ratholes there!)
A few points:
1) we should not get into the business of what receivers should do with
the information; our job is only to provide the interesting bits
2) the scenarios themselves should focus on a situation in which a reciever
is faced with. The requirements should flow from those scenarios. It
might
be worthwhile to note in the requirements if they pertain to a
particular
scenario.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html