On Nov 27, 2007, at 1:04 PM, Jim Fenton wrote:
What is relevant to SSP is whether the signer is asserting that the
From: header field is authentic. Or more specifically, whether the
signer is making that assertion in the specific case when the
address in the From: header field is the same as the signing
address. SSP has no other dependency on whether the signer is
asserting validity or is "merely" taking responsibility.
The question is who taking responsibility and for what?
Does the signing domain indicated From email-address use is
restricted? If so, this could then shift content responsibility onto
the From email-address identity. If not, the signing domain is only
responsible for permitting some unknown users access. Clearly,
granting access says very little about content. Just granting access
without email-address restrictions requires reputations to be based
upon a collective behaviour of users to which they grant access.
Part of me wants to say this it's vaguely silly for a signer to take
responsibility for a message that purports to come from themselves,
but which they didn't send. But I suppose RFC 4871 doesn't
explicitly call this out.
You are being rather vague by using the terms "who" and "send". A
signing domain does not author message content. A signing domain
might restrict From email-address use to just authenticated owners,
but it may not.
If there is consensus that this indeed isn't clear, we could easily
add verbiage to SSP stating that domains publishing SSP records
other than "unknown" MUST additionally ensure that they only sign
messages purporting to come from themselves when the address in the
From: header field is valid.
In other words, use of From email-addresses has been restricted to
authenticated owners. What happens when they wish to send a message
where a user is not authenticated, but where use of some critical
email-addresses are restricted. There are currently no existing
semantics to permit a mixed assertion, however actual use is likely to
confront such a mixture. And this must include assertions about third-
party domains (which includes sub-domains).
This more complex situation can be handled using TPA-SSP. Scope at
the From domain can indicated whether email-address use is restricted
or not. Within a third-party domain, which could be just a sub-
domain, an assertion for this domain's <tpa-label>._ssp record can
assert scope=F-i,S-i where both the Sender header's and the From
headers email-addresses are asserted as being restricted and that this
specific third-party signature is valid. The overhead is that of a
CNAME. : )
The TPA-SSP extension can handle almost any desired breakdown of valid/
invalid third-party signatures and valid/invalid email-address
assertions efficiently regardless of the signing domain.
Valid Third-Party Sig, Restricted Email-address
Yes Yes
Yes No
No Yes
No No
Yes Yes
Yes No
No Yes
No No
That way, we're putting the additional burden on those who publish
SSP records but are not trying to modify the meaning of RFC 4871 at
all.
Agreed. TPA-SSP does not modify the base draft.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html