Subject: RE: On Extensibility in MARID Records

From: "Jim Lyon" <[email-masked]>
Date: Fri, 18 Jun 2004 10:31:40 -0700

In discussing record sizes, Doug Otis constructs an argument about how
many address ranges or domain name references one could fit into a
512-byte DNS packet.  Sumamrizing his numbers, and filling in the blanks
from our actual proposals, we get:

               theoretical max   SPF today   XML as proposed
               ---------------   ---------   ---------------
Address Ranges              21          20                17
Domain Names                18          17                14

While I think that Doug believes this damns XML syntax, it actually
shows how reasonable XML syntax is.  There are probably only a handful
of domains on the face of the earth that send mail from more than 17
different address ranges.  Since that handful constitutes the largest
ISPs, any effort spent fetching their records (possibly through a couple
of indirections) can be amortized over a large number of mail messages.
(Doug's claims about bandwidth spent fetching records exceeding
bandwidth spent receiving email fails on this point.)

Doug then goes on with a bunch of calculations that show that, for
typical sized organizations, they're nowhere close to the limit.

He then says:
> The space that is claimed to be available will be consumed by
> perhaps a 60 byte XML namespace declaration. This is to allow
> vendors the ability to "innovate" and there would be no review
> of these declarations or associated payload. (A very bad idea
> in my view.)
and later
> Okay, now you pick two and then the next vendor picks a different
> two.  These great innovations don't fit without expecting these
> records to chain and chain and chain and chain and chain and
> chain and chain and chain...

This shows several misconceptions:

1. Vendors don't force anyone to publish any extensions.  If there
   are vendor-promulgated extensions, presumably a domain will only
   publish a record that uses them if that domain sees some value
   in it.

2. The current spec is carefully written to allow IETF-standardized
   extensions with no penalty.  This sounds like the right balance
   of burdens to me:  the standard way is cheap, and the non-
   standard way costs.

3. Regardless of what happens in this debate, there *will* be
   extensions.  A domain that decides it's useful to publish
   the night-shift janitor's Hilbert number will stick
       night-shift-janitors-Hilbert-number=7
   onto the back of their SPF record.  No standard can keep
   this from happening.  Indeed, domains experimenting with
   doing this is exactly what leads to follow-on standards.
   A major point of XML is that it provides a way for
   independent organizations to do this, *without needing
   to first coordinate with each other*.

Doug then goes on to make a number of comments about other extensions I
mentioned.  To be very clear, I am NOT seriously proposing these
extensions at this time.  I do NOT believe that they are all useful.
They're certainly NOT yet well thought-out.  I merely brought them up in
response to John Levine asking what kinds of extensions had been
considered.

-- jimbo

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Jun 2004 14:03:31 -0700

>                theoretical max   SPF today   XML as proposed

As I said, not all names have the same size, but it does show the
mischief a single record could cause by invoking this number of
redirects.

> bandwidth spent receiving email fails on this point.)

This fails to consider the number of queries required nor that only
addresses would be referenced in these smaller organization.  Just as
these large mail sites will require sequential queries (this does become
cached), those many smaller sites will have equally many reasons for
also listing more than a single record to be retrieved.  I use several
mail addresses, but only have an ability to send from a few.  If forced
by closed lists, it may become the norm for each site to have more than
one domain referenced in their record. Do you see a potential problem
yet?  Now you add the "report mechanism" and the "spy on remote users
mechanism" and the "where to mail your problem" etc.  These quickly
become more records that will be linked in this nearly endless DNS chain
of records.  No one forced them to add this stuff, but it is for the
consumer of this now serialized stone soup to consume.

> typical sized organizations, they're nowhere close to the limit.

This concept clearly goes beyond a reasonable limit.  How can this
mechanism be employed in transit if there is no consideration of the
workload generated or the problems created?  With many of these lists
likely to remain open to prevent endless problems a closed list will
cause, there will be no benefit whatsoever for those that provide mail
service to consider implementing this expensive mechanism.  

>    publish a record that uses them if that domain sees some value

Consuming this serialized stuff will be where problems occur.  Now that
you made it well beyond any standards process to control, what is left
but to abandon the entire mechanism.  Might as well; it will never fly.

>    of burdens to me:  the standard way is cheap, and the non-

So the standards process can dog-pile on as well as anyone else?

>    to first coordinate with each other*.

Use a SRV record and then no one will be "sticking" in anything that was
not specified.  How is this dog-pile is a good thing?  

If it becomes the norm for domains to include other domains in the
description of outbound mail to accommodate desires of users to use
their desired address, then even if these lists become expressed as
closed, the query process may never converge.  It will become an endless
search for the next record. This then implies a need for search
algorithms to handle great depths of recursion and redirection.  Of
course, a loop must be detected and there must be some limit assigned to
a depth this process may extend.  If I point to domain X because I have
an mail address there, then I find they have pointed to six other
domains because of their relationships, and each of these points to yet
more domains, where does it end?

Now you want to add to this by suggesting it is okay to grow these
records to experiment and innovate without coordinating with any other
vendor?  This process accomplishes nothing if it is only somewhat
possible at the MUA.  It does not deter any of the common abuses nor
does it allow any follow-up should there be a problem nor does it
mitigate any of the damage.

Again, the Fenton proposal for ensuring the identity of the user solves
this problem in a much cleaner fashion.  To prevent the abuse,
authenticate the MTA using a simple SRV record.  One well defined and
controlled query one time per session.

-Doug