In my technical opinion, the weight of LMAP has on DNS, coupled with the
complexity (or basic fact that coding needs to be done and development
resources need to be allocated), while it may address the problem, it is too
narrow in scope.
In other words, we should use the opportunity to add more information such
as server attributes so that we can begin to shift more logic or burden to
the client to use this upfront information. The client needs to go to DNS
to get the MX records anyway. So why not have it "get more" information
about the server itself.
This will help tremendously in reducing network bandwidth.
Just consider that if all this work is presumed to pay off at stopping (or
better managing) the anonymous access/spammer, the issue of overhead will
evolve to one of redundancy.
So I think the whole of idea of adding DNS records will be more "plausible"
if it contained more information (server attributes).
However, having studied and research this idea over the last few months, it
will only work with a change to SMTP as it has concepts to authenticate,
challenge and protect the client/server negotiation process using the server
attribute information. I do have an outline draft on this idea but stopped
to work with current directions instead.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "IETF MXCOMP (E-mail)" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Friday, March 12, 2004 12:06 PM
Subject: Real work items (Was: DNS etc.)
Before defining *how* the data is stored in DNS, we should work on
*what* that data is. There is a significant disagreement on
what kind of
data should be included among different proposals, and this
is something
that is more important than how the actual data is stored.
Agreed, moreover how many different ways do we need to express
the same data?
What is the best way to deal with the forwarding problem?
should we attempt to define a macro language as Meng has
done? Should we attempt some other means of addressing this
problem? Does this mean that the charter should allow
discussion of mechanisms other than pure DNS publication
rules?
This is akin to writing up the book before figuring out
what the cover page and the
title should be, as opposed to picking a title and the picture on the
cover, before writing the content.
We should probably discuss use cases and requirements.
I believe use cases would be very helpful. Not the normal
alice talks to bob use cases. I want to see the salient
header features.
My belief is that there are only really two interesting
use cases:
1) Mail is sent to alice(_at_)example(_dot_)com, possibly forwarded
under the same name via relays controlled by the sender
or receiver's ISP.
2) Mail is send to email(_at_)alias(_dot_)example(_dot_)com and forwarded
under a different name, either through the action of a
mailing list or a mail forwarding arrangement.
There are also uninteresting use cases like going through
open relays.
Case (2) is where all the corner cases come from. One way
to address this problem is by defining the actions of
forwarders that change names very carefully.
As much as some of us may be interested in your "war stories" about
fighting the "gods" of the IETF, this is not proper forum for
that type of discussion.
If it is asserted that a party has a legitimate interest in the
direction of a spec it is legitimate to point out that they should
be ignored.
Phill