ietf
[Top] [All Lists]

Re: The rights of email senders and IETF rough consensus

2005-12-19 12:59:30
If we standardize a technology, we are saying that technology solves
some problem. and that its usage has well understood and accepted
consequences.

It has to be acceptable to *the people who are involved*.  People who
are doing things contrary to contracts that they have signed, TOSes,
AUPs, employment agreements, etc, should not have standing and
should not be able to change the rough consensus of the IETF.

I think you have it backwards. 

Contracts, TOSes, AUPs, etc. can and do change frequently, as
conditions change.   IETF's job is to help the Internet adapt to
changing needs and conditions.  IETF should not make it more difficult
for the Internet to adapt to changing conditions by standardizing
protocols that only work in a narrow set of conditions - even when those
conditions are reflected in some providers' current contracts or
policies.

In many cases contracts, TOSes, etc. act against the legitimate needs
of end users - forcing users to give up valuable functionality and
giving them a crippled Internet.  IETF should design protocols in
such a way as to maximize benefit for all parties, not to favor some
network operators' perceived interests over those of users.   In
particular, just because some network operators impose constraints on
particular kinds of usage does not mean that IETF should standardize a
protocol that encourages those kinds of constraints.  Nor should network
operators be compelled by IETF to impose Procustean policy constraints
on all of their users simply because an IETF standard was not flexible
enough to accommodate diversity of needs.

Contracts, TOSes, etc. often inhibit the growth of new applications.
IETF protocols should not standardize protocols that deny valuable new
functionality to the public without careful consideration of the
tradeoff between functionality lost and functionality gained.  In
general, IETF protocols should promote the continued ability for the
Internet to support new applications that can benefit the public.

--

One problem that most of these DNS-based blacklists have in common is
that they're too inflexible.  A domain might represent anywhere between
zero and a billion or so email addresses.   Such a large set of users
can be extremely diverse.  It's not reasonable for IETF to standardize a
protocol that specifies policy for user of email addresses on a
per-domain basis only because that doesn't accommodate a diversity of
users' legitimate needs. Even if some large domains don't mind imposing
such a policy on all of their users at the present time, that doesn't
mean it's a good idea for IETF to impose that lack of flexibility on
all domains. Nor should IETF compel domains to accept a choice between
either restricting the way in which all of their users send mail (even
though they have legitimate reasons to do otherwise) or having the
domains' reputations suffer for failure to specify an inflexible
domain-wide policy.

Many of the DNS-based schemes seem to suffer from a dubious assumption -
that because DNS exists and is widely deployed and it's easy to add
information in TXT records, that a useful policy specification and
filtering mechanism can be implemented quickly.  This is dubious for two
reasons: one is that per-domain policy is often too inflexible, and DNS
and its infrastructure were not designed to specify things on a
per-user basis.  The second is that it ignores the work required to
define the behavior of other components in such a way that they'll work
reliably at distinguishing illigitimate mail from legitimate mail, and
to deploy those components.   Trying to make DNS do too much doesn't
save you time - it costs you time.

Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf