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 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. > > > To the extent the above is not sufficiently clear: > > The SSP document should contain text that discusses the overhead of > different modes of SSP use, specifically distinguishing between for > unsigned messages and use with signed messages. At the least, this > issue needs serious working group discussion, as well as review among > DNS experts.
The number of DNS lookups per SSP query is bounded at 3: the SSP record for the From: address, the domain of the From: address itself (to see if it exists), and the parent domain's SSP record. There are already quite a number of DNS queries that are typically associated with receipt of an email message, such as a reverse lookup of the IP address of the message. The comment you quote expresses rather a different concern: that the additional traffic associated with lookup of messages with a valid signature which is not an Originator Signature will be excessively burdensome. Can you explain what will lead to the generation of large volumes of mail signed by other than the Originating Domain? Even so, we're only talking about 3 lookups maximum. There are currently quite a number of queries that will almost always fail for a significant number of years into the future: AAAA queries. This isn't meant as a criticism of IPv6 deployment, but I haven't heard that DNS is melting down as a result, either. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
