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.)
On 6/18/2004 10:51 AM, wayne sent forth electrons to convey:
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, 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.