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.
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.
There is a trivial mechanism that can cut down SSP lookups to almost
nothing: don't query domains from which you've never received a valid DKIM
signature.
You are suggesting that a problematic design which imposes undue overhead is
remedied by a hack that has no long-term experience?
(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.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html