On Thu, 11 Nov 2004, wayne wrote:
In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0411102045350(_dot_)32295-100000(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
If I can convince them (which is not likely, but they have 0 deployment
right now, so maybe they are little more open to more extendable format
and its not a big change), then I think SES people and SRS really should
change to fit into BATV framework so that all can co-exist together
(right now that is not possible).
Why should SES and SRS change just because Dave Crocker, et al
reinvented the wheel?
Reduces collisions for systems designed to "rewrite" enevelope mail from
address. SRS does not work well with SES either. In fact there have been
number of schemes that change MAIL FROM to some special format and none of
them seem very compatible with each other or using same type of email
rewriting eventhough most of them preserve real username (i.e. normal
local-part).
Since BATV has 1 (one) deployed system, wouldn't it be much easier to
just abandon it and stick with SRS/SES?
I've looked at SES and looked at BATV and do not agree with those that
tell me that they are the same or that SES encompases BATV. To me BATV
syntax has more possibility to become real framework which defines the
inclusion of various types of signatures (either 100% private or
public-verifiable ones) into MAIL FROM address. I believe it would be
in best interest of SES camp to have signature that fits into standard
framework rather then have it with yet another signature format type.
P.S. The talk with Doag was very education on several other issues,
despite what you guys may think he's very very good at technical level.
I'll tell you more in posts tomorrow about the kind of problem that he
brought up that I think we should work more on.
I hate to say it, but no, I do not think that Doug Otis is "very very
good at [the] technical level." *IF* any meaning can be extracted out
of his long incoherent rants, I think you will find that a great deal
of it is bogus.
No, his arguments are just difficult to sort through especially when he
gets too heated in his pro-CSV agenda talk.
For example, his DNS poisoning stuff that he ranted about at the FTC
summit shows that he is missing really important things. The use of
random port numbers (djbdns for a long time and now bind) greatly
reduces the problem and the birthday attack that lets you poison a
cache in a few hundred attempts requires both the lack of random port
numbers *and* the same query, which isn't the case for an SPF record.
I've pointed that out too him. But he's correct that SPF documents
should mention the possibility of dns amplification DoS. They should
say that those clients that check SPF records should preferably check
operators one after another in order and if they dont they should check
all DNS lookups (that are to be done in parallel) and check and make
sure they are not the same (or going to the same dns server with lookup
that potentially could be the same). This should be in security section
of the draft so that implementors are aware and don't do it in bad way
that is easily exploitable.
I've tried many times to dig through Doug's posts for real
information. While it is clear that Doug is intelligent, it is also
clear that he spews a lot of BS wrapped in technical jargon and he
isn't worth listening to. I have long ago given up responding to him.
Maybe one on one you can get him to focus and maybe you were able to
get some good info out of him, it is certainly a possibility. If so,
please bring up the points. Maybe you can even act as a translator
for us.
We mostly talked on independent topics (I'm not the one to stop somebody
else from talking especially as he was giving me more examples on how
bad Microsoft is and how they screwed up IETF and couple other standard
bodies before and forced results that largely failed).
Of the things that are SPF related, I now agree with Doag that you can not
"hang" reputation system on SPF - its not precise enough because of having
to include all smart-hosts that can possibly be used by domain owner.
However as you know SPF was not designed for this in the first place, its
only Meng and some of his corporate friends that are trying so hard to
bring SPF into it instead of using something real based on crypto.
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net