[ietf-dkim] Tracing SSP's paradigm change

[Dave Crocker]

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