OK, admittedly I've given up on following every single thread in this list
because the arguments have gone way over my head. And before you even
suggest that I shouldn't be here because of that, understand this:
I HAVE TO IMPLEMENT THIS GARBAGE.
I have to install it and support it in the field. I have to explain to
clients why it's not working and they're still getting complaints from people
about mail that didn't really come from their network. I have to understand,
if not how or why it works, the reason for it to work and how to troubleshoot
it when it doesn't work.
Which brings me to the point of this rant. Exactly what are you trying to
accomplish here? All of it.
Because it's gone far beyond simply verifying a sender's address or a
forwarder's address and into theological - not even technical but religious!
- arguments about DNS overloading, SMTP overloading, breaking existing
semantics of each, building new semantics that don't even fit in the existing
rules (ie: DNS packet sizes), a servere unwillingness to abandon consistently
abused things. And that doesn't include all of the political infighting,
harsh business accumen, introductions of proprietary / patented crap in
doomed efforts to sell said crap, obscene stubbornness and ignorance of hard
data, and I don't know what else anymore.
If you're as confused as I am, speak up. The 60th IETF is four weeks away
and this motley crew's supposed to come up with passable documents by then.
If something's not clear make sure you bring it up or it won't be addressed
until too late.
I'm beginning to appreciate what Steve Atkins, another tired old sysadmin,
first asked me a year ago: "Why would I want to do this? What benefit is it
to me? What's the cost?" One of the reasons wayne said DMP-02 is a "solid
i-d" is that I tried really hard to answer Steve's questions. And those
answers came at the cost of much rewriting.
Since Meng, Harry, Bob and others in their camp were charged with drafting
this stuff and you've now had a chance to be thoroughly nitpicked, please you
three - explain what you're doing so a tired and confused network
administrator can understand it. And tell me what I have to do to implement
it, even if I have to write it from scratch in C or Perl or (Gaia forbid) VB
or Python or whatever. I'm not looking for source code, I'm not looking for
examples and it doesn't have to be a multi-page essay written so a
five-year-old can read it. Just answer the fundamental questions tersely:
Who, What, Where, When, Why and if you wish, How.
Gentlemen who wrote these drafts: Ignore the nitpicking diatribes of your
fellows, just for a moment, and try to answer these questions. This, to me
the tired old sysadmin, is the acid test. I will not be the only tired old
sysadmin who has to implement what you write.
IPSec is now my favorite example of how to confuse the hell out of a tired
old sysadmin. It's supposed to be the wonder drug for inter-site
connectivity, yet it's confusing as all Hell, requires cooperation between
differing entities in the case of third-party vendors providing services (ie:
computerized reservation systems for travel agencies) which never exists,
different implementors using different language, and, ugh, doesn't even work
half of the time between differeing hardware even when you do follow the
cookbooks to the letter. And my security-freak friends wonder why I stick
with PPTP when IPSec is So Much More Secure.
--
PGP key (0x0AFA039E):
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>