Dave Crocker wrote:
Michael Thomas wrote:
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.
This has not changed in years. Maybe you've just become aware of it. And
the problem here remains with unsigned traffic. Third party signatures
are
very rare beasts.
The requirement to have i= match From domain was added between the -02
and -03 versions, sometime during Fall 06 and Winter 07.
On reviewing the working group archive, I have not succeeded in finding
any discussion either of changing the SSP paradigm to apply to signed
message or of the problematic selection of the rfc2822.From field,
rather than rfc2822.Sender field domain.
I recall making a point a number of times in the working group,
verifying that the group agreed that SSP applied (only) to unsigned
messages.
RFC 5016, section 5.3 requirement #1:
1. SSP MUST be able to make practices and expectation assertions
about the domain part of a [RFC 2822].From address in the context
of DKIM. SSP will not make assertions about other addresses for
DKIM at this time.
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
I just checked and this requirement has been in the requirements since
the very first draft. If you objected, it apparently didn't get much
consensus.
(By contrast, a design that relies on caching would be using a
well-understood and accepted mechanism which is accepted as altering
query dynamics reliably, though not perfectly.)
The current SSP draft does make use of DNS caching, and it doesn't
seem to be any more onerous than SPF/SIDF -- probably less. We've
been running it for a year and a half and haven't noticed anything
even remotely alarming about it.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html