On Dec 3, 2007, at 3:37 PM, Dave Crocker wrote:
3. Scope and scale of query traffic
SSP originally was constrained to apply only to unsigned mail. The
current specification applies to unsigned messages *and* signed
messages where the DKIM i= domain name does not match the
rfc2822.From <addr-spec> domain. This is a considerable change in
the nature -- and potentially a considerable change in the amount of
query traffic -- that SSP causes.
The desire here is to qualify the From header for transactional
messages.
The draft does note that initial receive-side adopters of SSP will
find no SSP DNS record. However the draft does not address the
adoption and use impact of being expected to make a query that will
almost always fail for a significant number of years into the future.
A policy statement that can be applied more broadly, where benefits
extend beyond just qualifying the From header, would suit more than
transactional messages. Adding Scope to policy could more broadly
apply to all originating headers when handling "normal" messages.
This policy could also clarify what is implied by use of the i=
parameter.
The current use of the i= parameter is clumsy. Matching the i=
parameter precludes use of a g= restricted keys from signing Sender
headers to spoof a From header. The ALL or STRICT assertions must
constrain the i= parameter to disqualify restricted keys not signing
the From header. Adding scope can eliminate these constraints.
Attempts at providing a minimal set of assertions has lead to this
very sub-optimal policy mechanism this is only suitable for
transactional messages. Most domains use the full set of originating
headers. There is also a need to partition policy to suit how email
is being used. Who is signing is the place to establish such a
partition. Users SHOULD NOT see well-known domains use other domains
to establish different policies. Policy partitions can transparent by
introducing Scope and a TPA-SSP label. These two changes offer
significant benefits.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html