ietf-clear
[Top] [All Lists]

[ietf-clear] Re. CLEAR Charter

2004-10-01 13:52:15
On Fri, 2004-10-01 at 12:50, John Leslie wrote:
] Authentication, authorization and accreditation each can be useful.
] Because accreditation involves new functional territory for Internet
] mail, the validation specification will first provide for private
] accreditation techniques, such as privately maintained whitelist and
] blocklist tables. 
  ^^^^^^^^^
   blacklist?

   This language went in because Dave Crocker wanted it, over my mild
objections. Dave assured me there would be significant stress induced
by opening the accreditation issue; and I agreed to shut up.

I was requested not to use the term blacklist.  Sorry, I was wrong to do
so.  It has a legal history with broader implications than blocking
addresses.  The term I was asked to use was blackhole list.  This seems
trifling, but I am not a lawyer.  I would suspect the term block list
would also avoid implications involved with this term.

   Nonetheless, "blocklist" usually means fitering CIDR blocks of IP
addresses; while I suspect we need to at least _allow_ private listing
of EHLO domains which individual sites choose not to trust.

Normally, having a record or not having a record was the deciding
factor.  To move to a broader range of decisions, then the term
reputation makes sense.  If this list also makes assertions of
affiliations, then the term accreditation makes sense.  Establish an
industry accepted policy where, when there is an agreement to these
terms of this policy, the domain would be affiliated with the
organizations that administer resolutions pertaining to the terms of the
agreement that allows the assertion.

   I'm still not convinced it makes sense to partition our work along
these lines. The DNA portion of CSV is _quite_ minimalist: merely
_allowing_ a standard method for listing of accreditation service(s)
which favorably rate the (EHLO) domain, and not requiring receivers to
pay any heed to these listings. IMHO, we'd be poorly advised to deploy
CSV without that much.

I think there would be a fair amount of value in making the HELO domain
visible only when this domain is validated using CSV when isolated from
the local MDA.  That adds value to this mechanism without the need for a
blackhole, reputation, or accreditation service. With respect to the
details of DNA, you know I am interested. : )

   (We'd also, IMHO, be poorly advised to try to nail down a "solution"
to any particular "spam" problem through accreditation standards.)

I see accreditation useful for bulk emailers wishing to differentiate
themselves.  It is difficult to know, looking at content or volume to
know when these mailers are following an opt-in only policy. Having a
class/state assertion rather than a quality assertion makes for a
simpler solution.  Allowing a flag that indicates an affiliation to a
group that assures BCP regarding the sending of mail seems like a good
way to go, hence the term accreditation.

This topic touches upon the constraints declared in the charter. I am
not trying to get ahead, but it is hard to know how to keep this as
simple as possible and yet allow reasonable deployment in a
non-disruptive way.  The term "basic accreditation rating" should read
"basic accreditation information" as rating and accreditation seem at
odds.

Changing DNA to DNR for reputation along with the CLEAR wg reminds me of
my stint with my father's ambulance company.  Deciding whether to
resuscitate and what you shout before hand. ; )

-Doug