"Mark Lentczner" <markl(_at_)glyphic(_dot_)com> wrote:
I think your message contains two distinct issues:
On Aug 27, 2004, at 11:06 AM, Douglas Otis wrote:
The Protocol draft mandates a minimum of 10 DNS text script macro
evaluations. These scripts may reference any number of A, AAAA, MX,
PTR, TXT, and SPF2 resource record types. ...
This seems to be a concern that the type of processing limits in the
draft are unsuitable for keeping the amount of DNS traffic down to a
reasonable level. Several other people (Wayne in particular) have
suggested other types of processing limits for the draft that would
more precisely limit DNS queries. Do you have a particular proposal in
mind?
I view this task as finding solutions that obtain the following goals:
1) A suitable identity for performing MTA reputation checks.
2) Allow the domain to constrain their mail to sets of MTA servers.
3) Allow the domain to list typical MTA servers, if not constrained.
4) Allow a means to recommend a listing service.
5) Minimize the impact upon the existing mail infrastructure.
Contrary to a view this must be done by applying a Band-Aid, there should
be a change in how this is structured. This change in structure will
arrive at these goals. A side benefit in doing this is that the IPR
problem is avoided as well.
The Protocol draft also allows for ?open-ended? definitions by
appending notation such as ?+all? or ??all?
I think you are concerned here that the draft allows domains to publish
what you would argue are unsafe and detrimental records. Do you have a
specific proposal for changing the draft to address this issue?
Sender-ID does not properly provide for goals 2 and 3. Sender-ID attempts
to combine the MTA authorization with the Mailbox Domain authorization.
This creates a problem. Mail is often relayed through a series of servers
and is not always end-to-end. By combining these functions, this creates
a problem of "validation promotion" where at one server, the message would
be seen as outside the prescribed Mail Channel, but at the next, the
message would be seen as inside the prescribed Mail Channel. Users will
find that by offering an "open-ended" list to achieve the lesser goal 3,
may also find these records being exploited to send spam using their
identity, but now as fully validated. Expecting checks made at each MTA
as a means to protect the integrity of the RFC2822 information is also a
problem.
Splitting the message authorization from the MTA authorization solves the
problem with the number of DNS lookups. Authenticate the MTA and validate
its authorization. The MTA authentication and authorization can be done
without adding any additional DNS lookups. MTA authentication provides a
domain that CAN safely be used for Goal 1. By having the Mailbox Domain
reference a list of MTA domains, either as a restriction or to indicate a
nominal, this is achieved using a non-sequential DNS lookup. This solves
the problem of "open-ended" lists being exploited by spammers. This
solves the problem of "validation promotion". This solves the problem of
ISPs needing to include Resent-From headers. This allows the MTA to be
authenticated without breaking the operation of list servers or
forwarding.
Solution:
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt
If your concerns are truly TECH-ERROR concerns with the protocol draft,
please suggest specific ways to fix them.
I have suggested very specific ways to fix them.
If your concern is that the draft is so broken that the working group
should abandon it and proceed with discussing your draft, then that is
much more than a TECH-ERROR issue. Perhaps it is a DEPLOY level issue, or
perhaps a meta-level issue to be brought up with the working group chairs.
The draft has been transformed dramatically several times in its recent
history. As I see it now, the current structure is unworkable. Changing
the structure provides virtually all the same features far better but with
MUCH less overhead and damage to the existing system. By making these
changes, it would also dramatically reduce the cost of tracking spammers.
-Doug