[offlist, and this time I remembered to remove the Reply-To: header
that my MUA automatically adds.)
In
<81AC085044D04B429F5FB883D94FA1AF42A6DD(_at_)df-fido-msg(_dot_)exchange(_dot_)corp(_dot_)microsoft(_dot_)com>
"Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com> 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.
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.
Yep, I agree, although having a small pointer that says "oh, btw, if
you are interested in this stuff, look here" can be useful.
2. "Here's why you should accept mail from us" and "Here's how
to tell whether it's really me" are seriously intertwined.
Agreed.
3. Today's SPF syntax isn't rich enough to adequately capture
that intertwining. XML is.
I disagree.
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.
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.
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.
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