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