Subject: RE: Against Extensibility in MARID Records

From: "Jim Lyon" <[email-masked]>
Date: Fri, 18 Jun 2004 09:49:22 -0700

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.

---

From: wayne <[email-masked]>
Date: Fri, 18 Jun 2004 12:51:28 -0500

[offlist, and this time I remembered to remove the Reply-To: header
that my MUA automatically adds.)

In <[email-masked]> "Jim Lyon" <[email-masked]> writes:

> Let me illustrate by way of an example.  [snip]

I think you may want to clean up this example a tiny amount and repost
it to the thread that Marshall and Andy reserved for examples of what
XML can represent, but can't be done in the SPF syntax.

I remember you giving this example at the dinner during the interim
meeting.  It probably won't surprise you that I have considered it and
found the argument lacking.  After all, if I thought it was
compelling, I wouldn't be arguing against XML.

Mind you, it isn't the concept that I dislike, quite the opposite, I
like it.  I just don't see the need for XML.

My argument against needing XML is:  If a receiver is going to do that
kind of checking, there isn't much reason to not do it automatically
for all include: mechanisms.  Yes, a reputation for a.hotmail.com may
not exist, but then, maybe because of the way hotmail has devided up
their MTAs between dialups or country, a.hotmail.com may be a much
larger source of spam than b.hotmail.com.  A spammer who publishes
"v=spf1 include:optinrealbig.com -all" will almost certainly not say
to check the target's reputation, but a receiver may find that very
useful to check.

>    "here's stuff for the benefit of people inside my domain"

Yep, I agree, although having a small pointer that says "oh, btw, if
you are interested in this stuff, look here" can be useful.

>    to tell whether it's really me" are seriously intertwined.

Agreed.

>    that intertwining. XML is.

I disagree.

>    determine which fragments of a record they're speaking

I agree with this.  XML is a great tool for many things, but I don't
think it is the best tool for the job here.

> On this point, I 100% agree.

Actually, I think a serious of DNS lookups, especially if done in
parallel, will be quicker than a single TCP transaction.  The
three-way handshake on startup and the four-way teardown really kill
the performance of sending one large TCP packet.

-wayne

---

From: Roy Badami <[email-masked]>
Date: Sat, 19 Jun 2004 03:22:47 +0100

Hmmm, I have to say I'm really not that interested in the reputation
of my ISP...  I'll send mail from my own MTAs, and their reputation
will hopefully be based solely on the mail that my systems generate...

My gut feeling is that if you're forced to use your ISPs MTA against
your will (which boils down to being a residential cable/DSL customer)
then your ISP's reputation is going to be pretty low anyway (simply
becuase of the nature of virus infected and compromised machines that
exist on a typical residential broadband network).

Surely MARID makes more sense in a world where people (again)
configure their MTAs to deliver direct, rather than smarthosting off
their ISPs...?

      -roy

---

From: Aredridel <[email-masked]>
Date: Fri, 18 Jun 2004 21:03:08 -0600

> exist on a typical residential broadband network).

Agreed -- in the short term. In the future, though, I think we may see a
drop in such activity, so the long term seems brighter to me.

> configure their MTAs to deliver direct, rather than smarthosting off

For sure. For me, that's a primary goal -- a sort of rebirth of end-to-
end in email. If you can hold people (or at least groups under a domain)
responsible directly, there won't be so much policing neccesary.

Ari

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 18 Jun 2004 20:38:49 -0700

I don't find Jimbo's arguments compelling.  In the two recent specific 
examples, I think things are wrong because I expect MARID-based software 
will check reputation services just on the domain initially looked up; 
checks on referenced domains isn't necessary, and I don't see why it's a 
good idea.  The third example is of something that I think MARID should 
NOT support - reputations should be tied to domains.  Not to various 
sets of servers that are authorized to send b a domain. 

We need to concentrate on what is the least we need to do to accomplish 
our goal.  Are all these extensions necessary or helpful in achieving 
M.A.R.I.D. or the larger <make spamming very difficult> goal.  No, MARID 
will enable antispam efforts to be more proactive and less reactive.  
These extensions would return to a reactive mode.  

Another thing is that if regular SPF and new SPF-ID records are both 
going to be OK, then the regular SPF record has to support this stuff.  
If XML has stuff that only XML can have, this symmetry is broken!

Hence my opinion that regular SPF records, and NO XML is the way to go.  
I don't think a compromise is a good idea because it will slow adoption, 
which is far more important than these add-ons.   Speed and simplicity 
and breadth of adoption is what it's about.  That's why I want to see 
SPF records use to validate the EHLO.  It'll (play the same record track 
yet again) solve the problem without the headaches of SRS or end user 
changes that regular SPF or the new one will require, and hence be much 
faster to adopt.  BTW, Someone at the interim meeting smeared this 
argument in a content-free way (Ted???).  I've presented it in detail 
here and it went unchallenged.  If it's to be challenged, the proper way 
would have been to respond to my detailed presentation of the argument.
Details of my argument as to why CSV  is is likely to be adopted so much 
faster and more easily are here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg01226.html and
http://www.imc.org/ietf-mxcomp/mail-archive/msg01175.html.  Ted, or 
whoever made that comment, I'd appreciate a response to my argument that 
is not just an opinion, but a counterargument. (Apologies if I've 
misidentified the speaker; it was the person at the end of the front 
main audience table, audience left, if that makes sense.)

>the performance of sending one large TCP packet.
Wayne, reread what John said.  Your reply indicates you think he's 
comparing DNS over UDP with XML over TCP.
He's not.
He's comparing DNS over TCP with XML over TCP.
Still, it's true: a series of DNS over UDP lookups is cheaper than the 
alternatives.

---

From: Philip Miller <[email-masked]>
Date: Sat, 19 Jun 2004 10:14:05 -0400

> drop in such activity, so the long term seems brighter to me.

With some ISPs, we'll see a drop in that activity. Comcast, for example, has 
been rather proactive about rate-limiting outgoing SMTP through their 
smarthost. On the other hand, there are many ISPs that don't care.
I'd much rather the alternative, that only my reputation applies to my mail.

> responsible directly, there won't be so much policing neccesary.

That is probably the strongest reason I support the MARID effort. I 
currently cannot send directly to certain large domains because I'm on 
residential cable.

This is also the reason I support something simple and lightweight, that 
protects HELO or MAIL FROM instead of body headers. If the recipient has a 
domain that will put its reputation on the line to vouch for a message, it 
doesn't need to be the one that appears in the body.

We need to create the smallest possible system that can authenticate one 
protocol field in an SMTP transaction. From that, this or another group can 
develop stronger mechanisms for combatting forgery and spam, but not until 
after basic authentication hsa been deployed.

Philip Miller

---

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2004 16:18:27 -0400

>     v=spf1 +indirect:msn.com +indirect:comcast.com -all

If I were a spammer sending Ci@l1s spam through zombies on MSN and
Comcast, I agree that this is the SPF record I would use.  But it is hard
for me to imagine why anyone else would believe an attempt to piggyback on
MSN and Comcast's reputation unless they already had other reasons to find
me credible.

> my mail is not spam is exactly a function of one of my ISP's

Perhaps, but you don't get to say that MSN and Comcast vouch for you.
They do.  That's why it's pointless to self-publish any reputation info
beyond pointers to other sources that people might be willing to believe.

In any event, I think that we need to take Vint Cerf's recently cited
comments to heart here.  He commented (roughly) that the Internet was
built by doing experiments and writing up the results so that people could
see how well they worked.  At this point the only MARID-like thing that's
had the benefit of experiments is SPF.  SPF has all sorts of shortcomings
that we all know, and I find even SPF overcomplex, but at least we have
some idea how hard it is to publish and to decode.

I'm not ruling out the possibility that people will find useful and
interesting info to put into a MARID record that would be complex enough
to merit XML, but at this point, it's all hypothetical.  The reality is
that for a lot of us, an XML parser would double the size of our SMTP
daemons, and it'll take a more compelling argument than "we might come up
with something" to make it worthwhile.  The sensible approach is to send
an SPF-ish design down the standards track, and to keep experimenting.
Given the reception in the SPF community, they're not going to parse XML
no matter what MARID says, and we need to keep in mind that the IETF can't
tell anyone to do anything they're not inclined to do.

If experiments show that recipients can use big rich XML data to deal with
spam significantly better, great.  At that point, it should be easy to
send MARID 1.1 with XML along the track.  But you have to do the work and
show us the horse before you can get this cart moving.

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 19 Jun 2004 16:47:53 -0500

On 6/19/2004 3:18 PM, John R Levine wrote:

> If experiments show that recipients can use big rich XML data to deal
> with spam significantly better, great.  At that point, it should be
> easy to send MARID 1.1 with XML along the track.  But you have to do
> the work and show us the horse before you can get this cart moving.

I pretty much agree with John but on a slightly different tack.

I think we (for some value of 'we') are trying to sneak email policy into
an authentication scope, which is cart-horse inversion, as John says. If
we really want to detail an email policy architecture, let's work on that
as a discrete problem -- heck, we might even end up with receiver-side XML
architecture of some kind. Instead it seems like we're trying to come up
with excuses to sneak XML into DNS and declare that we've got ourselves an
email policy framework. Backwards.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 20 Jun 2004 01:11:46 -0700 (PDT)

> email policy framework. Backwards.

I STRONGLY agree with above statements. XML would likely be great for 
creating wide-scale policy document and I agree with Jim that is what
SPF will likely need to become in the future. But this kind of document is 
almost certain to be larger then what can be put into DNS and we need new
protocol for it. At this time I believe we should leave SPF syntax as is
with maybe some additions for better extensibility (possibly new scoping
operator) and add ability to refer to different external policy service 
from SPF record. This serves as quick patch that reuses current architecture
and can be deployed quickly (which is what this was all about).

The new policy service can then be developed in normal IETF process 
and can reuse current work done by Microsoft in regards to SPF/XML 
and <ep> document and define how to best get to users but would not have 
constrains of having to be fit into records that using DNS database 
service forces on us, nor would it have constraints of single-key data 
lookups which allows for user wildcards and other features. 

-- 
William Leibzon
Elan Networks
[email-masked]