ietf-mxcomp
[Top] [All Lists]

RE: Against Extensibility in MARID Records

2004-06-17 23:43:25

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.

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.

The goal of MARID, the last time I checked, is to do authentication: "mail
with these characteristics really is from us."  SPF and its descendants
are well specified, and every MTA that looks up Sender ID data will use it
the same way to verify whether a message matches a domain's rules.

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.  We are just
beginning to understand reputation systems, but one thing that's clear to
me that reputation will mostly be vouched for by third parties, and
there's little a domain can say on its own behalf beyond "look at what
these guys say about us."

Inbound requirements are certainly an interesting area to think about, but
I see no reason to put them in the same database as MARID.  They're looked
up by senders, not recipients, and keyed on RCPT TO or header To: and Cc:
addresses, not the addresses that MARID uses.  Is there an operational
benefit to putting them in the same record?  Not that I can see.

Private domain info is yet a third separate area, again looked up
differently. My MTA delivers mail for a lot of different domains into
overlapping sets of mailboxes, and if I were looking up internal stuff,
I'd want to key it by POP mailbox name, not incoming domain.  Does it
belong in the same record as MARID?  Again, I don't see any advantage to
doing so.

PS: John also continues the misconception that anything that uses XML
will be big enough to require DNS TCP.

Once again, I didn't say that, and I have to say I don't understand this
point.  On the one hand I see an argument that we need to be able to load
arbitrarily much stuff into a MARID record, and now it seems like you're
saying that in fact nobody will do that.  If you plan to load all of your
spam related info into the MARID record, the record will get big, and you
have to be prepared to face the consequences of needing vastly more TCP
DNS transactions than before, unless you're saying that there'll be so few
of them that recipients can just ignore any MARID records that don't fit.

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.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.