ietf-mxcomp
[Top] [All Lists]

RE: Against Extensibility in MARID Records

2004-06-18 09:49:30

I said: 
In arguing against extensibility, John Levine argues that it's a bad
thing (he used the word "chaotic") to have information in a MARID
record
that is not understood by everyone.
In response, John said:
That's not what I said or what I meant, although I can see how you
might have misread it to say that.  What I meant is that it's a bad
thing to have info in the record that doesn't have a consistent and
well understood meaning.

I'm sorry I misunderstood you.  Yes, we definitely want to be in a world
where if a domain publishes something, everyone who understands it
arrives at the same meaning (including the publisher).  My premise is
that XML is well-tailored to making this possible.

John said:
The proposed extensions I've seen are about reputation "here's why
you should accept our mail", or inbound requirements "here's how
you can persuade us to accept your mail", with a few items private
to a domain "here's how MUAs within our network can decode headers
added by our MTA."  It strikes me as poor design to smoosh all that
together.

Your argument has some merit with respect to mushing these categories
together, and I could be persuaded that separate documents make more
sense.  However, I submit that the authentication stuff this group is
working on is just a subpart of "here's why you should accept our mail".
Furthermore, the reputation part of "here's why you should accept our
mail" is in many cases going to be intimately intertwined with where the
mail came from.  Separating these will do more harm than good.

Let me illustrate by way of an example.  Suppose I have a small domain
with no reputation.  Suppose I'm a customer of both MSN and Comcast, and
I send some of my outbound mail through MSN's mail servers, and some
through Comcast's mail servers.  As things currently stand, I'd publish
a MARID record like:
    v=spf1 +indirect:msn.com +indirect:comcast.com -all

This authenticates me very well (assuming that MSN and Comcast each do a
sufficient job of policing their internal networks to keep other
customers from masquerading as me).

When we get into the question of reputation, the argument goes something
like:  If you get mail from me through MSN's mail servers, you should
believe it's not spam because MSN does a good job of keeping its
customers from sending spam.  Similarly, if you get mail from me through
Comcasts's mail servers.  The degree to which you as a receiver believe
my mail is not spam is exactly a function of one of my ISP's
reputations.

Using invented syntax, I could say something like:
    v=spf1 +indirect:msn.com/targetrep +indirect:comcast.com/targetrep
-all
which gets the point across nicely.

Contrast this with the case of hotmail's record. Hotmail has more
address ranges for outgoing servers than fits into a single DNS record,
even using SPF syntax. So they publish something like:
    v=spf1 +indirect:a.hotmail.com +indirect:b.hotmail.com
+indirect:c.hotmail.com -all

In this case, the indirections are a mere implementation detail, and
receivers shouldn't attempt to read anything into the fact that they
received a message from the "b" list of servers instead of the "a" list.

In short:

1. "Here's how you can persuade us to accept your mail" and
   "here's stuff for the benefit of people inside my domain"
   *are* separable.

2. "Here's why you should accept mail from us" and "Here's how
   to tell whether it's really me" are seriously intertwined.

3. Today's SPF syntax isn't rich enough to adequately capture
   that intertwining. XML is.

4. The XML world has lots of facilities to help two parties
   determine which fragments of a record they're speaking
   the same language on. 

-- Jim Lyon

PS: John also said:
If the record is indeed too big for UDP, I hope it's obvious
to everyone here why following a pointer to a URL is the same
speed as falling back to DNS TCP.

On this point, I 100% agree.