Scott Kitterman wrote:
On Tue, 01 Aug 2006 17:39:58 +0100 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> 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!)
Yes. I would also say that is explicitly not a requirement that this be
done without breaking some existing e-mail functionailty. I don't think
it's doable otherwise.
I expect that this is a choice that would only be taken by a small minority
of domains that are:
1. Substantial phishing targets.
2. Willing to accept the collateral damage.
I do think it important to specify this type of approach.
I agree about the collateral damage part and it being acceptable for
some audiences but what I'd really like to do is phrase these in terms
of what the signer's practice/policy is instead of what the signer hopes
the receiver might do.
In particular, it seems that there are two different cases:
1) I sign all of the mail from this domain, and I don't expect that the
places I send will suffer from transit damage
2) I sign all of my mail but I may send to places that may incur transit
damage
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html