On Fri, 2004-10-01 at 22:53, John Leslie wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
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,
The more I think about this, the more I feel that trying to skirt
around accreditation will cause more confusion and delay than tackling
it straight on.
Also, I believe MARID got in a lot of trouble by trying to manage
discussion to a pre-conceived idea of what the issues would be.
] such as privately maintained whitelist and
] blocklist tables.
^^^^^^^^^
blacklist?
I was requested not to use the term blacklist.
It appears Doug is saying that MAPS chooses not to call its RHSBL
a "blacklist". That's fine with me, but it's a business decision, with
little or no applicability to engineering discussion outside MAPS.
Costs of providing these services is largely from legal preparation.
These preparations become part of the engineering effort irrespective of
the service provider.
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.
Here we have Doug in his most endearing stream-of-consciousness
mode. I've read this five times so far; and have yet to glean a
clear meaning.
I was acknowledging my inappropriate use of the term. A common term
used for setting up routers is blackhole and block list also seems to
accomplish the same goal. This term is more appropriate, in that it
does not suggest broader concepts typically associated with
blacklisting, as used during the McCarthy era for example. Again, I am
not a lawyer, but have been advised this term is inappropriate.
Regardless, "blocklist" in the charter context obfuscates, IMHO;
and leaves us without clear guidance on what we're expected to do.
My strong opinion is that the current DNA I-D is about right: it
defines a mechanism at the MAY level for recommending an accreditation
service to check.
As Dave Crocker has indicated, this has been changed to just list.
There has been universal agreement in MARID that reputation services
(under whatever name) will be an essential part of any implementation
of spam-abatement. While spam-abatement is not within the scope of
CLEAR, we have ample experience with blacklists to know that they
experience _serious_ lag in recovering from a bad situation. I view
the DNA mechanism as a low-level tool to enable quick recovery.
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.
It's all to easy to argue over which word to use, only to end up
with everyone agreeing which word, but disagreeing what they mean
when they use it. I'd rather not start down that lane.
This discussion is more about where this technology has been and less
about where it is going. Accreditation is a significant departure and I
was attempting to cover the meaning of block list, reputation list, and
accreditation list.
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.
This is a very reasonable thing to want.
I'm not clear, however, that it belongs in the CLEAR charter. ;^)
I don't believe we can accomplish an "industry accepted policy".
Having the means to express 'state' with the accreditation information
seems rather fundamental. I would also expect such BCP would be outside
this WG as well. Providing for this assertion would be the first step,
and until this becomes defined, it can not be used. Once the BCP is
defined and adopted, then it can be used.
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.
I agree there would be substantial value in that -- but it's a MUA
issue, and the lead time on MUA changes is 2-10 years.
Yes, but it would be a valuable feature for any MUA as a tool to prevent
spoofing and phishing. It seems that working with various MUA vendors
would ensure implementation issues are covered. A BCP regarding the use
of CSV information by the MUA may be a follow-on document. There are a
few technical issues involved.
In the meantime, value will come from recording the CSV authentication
and authorization -- largely for purposes of tracking problems after the
fact. Alas, absent reputation information, tracking is problemmatic;
and outdated reputation information is considerably less useful.
I suspect reputation will be a hybrid approach using RBL and RHSBL where
the RHSBL trumps the information within the RBL to provide a solution
for those using shared or dynamic address space and also provide some
"filtering" relief.
That adds value to this mechanism without the need for a blackhole,
reputation, or accreditation service.
To the extent Doug means that we don't need real-time rejection, I
partly agree. There is certainly utility without it, so long as we
find a way (such as BATV) to ensure we have a useful bounce address.
Absent a useful bounce address, we need to try our best to reject at
SMTP time (if at all).
Beyond the real-time rejection issue, I think reputation information
_is_ necessary. Besides, real system administrators _will_ be using
reputation information -- or they'll face DoS by sheer volume of spam.
Nod.
With respect to the details of DNA, you know I am interested. : )
Indeed. Doug and I have been batting this around. I agree with most
of his thoughts on what a reputation report to a receiving SMTP client
should look like. I just don't agree that such reports should be within
the scope of CLEAR.
Are you suggesting to move DNA out of CLEAR?
(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.
Indeed, Doug and I agree that "accreditation" is the right name for
the services recommended in DNA PTR records. We disagree on whether it's
practical to try to tie such accreditation reports to BCP standards.
IMHO, such services will employ lawyers. :^( Plural. :^( Writing in
several different languages. :^(
Yes, these services will have ugly contracts and many lawyers. The
general guideline regarding what is considered acceptable practices can
be referenced and expressed in one language. This is to provide an
understanding what is meant by a generalized assertion. I would hope a
draft could enable making an assertion without getting bogged down in
the details of the assertion meaning. This meaning would be an industry
wide effort. It might even make sense to allow a few levels to this
assertion to allow differences of opinion, and let the market place
decide what level is acceptable.
This topic touches upon the constraints declared in the charter.
Continuing the draft charter:
]
] A DNS-based technique for querying external accreditation services will
] then be added. Details (technical and policy) about the operation of
] external accreditation services is outside the scope of this working
] group. Only the ability to query for basic accreditation rating is
] within scope.
This may or may not charge us to work up what Doug wants: a standard
for the query by the receiving SMTP server. I am quite willing to work
on that, provided we keep it clear that it's quite separate from the
DNA PTR accreditation-service stuff. DNA intends to specify the minimum
essentials for a fast-recovery system, wherein the reputation services
which will be queried by receiving SMTP servers can find the information
they need to evaluate the accreditations. For that, there _must_ be a
standard format to verify that a particular domain is accredited, plus
a fuzzy way for humans to find what the accreditation standards are.
Any attempt to nail down the accreditation standards ahead of time is
doomed to fail, IMHO.
OTOH, it _would_ be possible to nail down _some_ reputation standards
for one kind of report to the receiving SMTP server (provided that other
options are available), and this could have substantial benefits in
terms of simplifying the programming of necessary changes to MTA software.
My concerns regarding a level rating system for a domain, like one would
used to rate a movie with 3 out of 4 stars, implies comparison. This is
bad with respect to the information required to justify such a rating.
Currently the DNA proposal offers:
'A' for Strongly Recommended
'B' for Recommended
'C' for Unknown
'D' for Not Recommended
'E' for Strongly Not Recommended
This should be changed to something more along the lines:
'A' Good
'B' Good with pending complaints
'C' New (unknown)
'D' New with pending complaints
'E' Bad
This avoids the very difficult task of justifying the rating.
Comparison would require exposure of the entire database. In my
example, Bad would be based upon well defined rules or criteria applied
universally to all domains independent of other domains. Good would not
be bad. Good with pending complaints could be a domain that may be on
their way to becoming bad, but once acknowledge, the state would revert
to good. This would assist good domains to retain their good status and
allow receiving domains the option of waiting for an issue to be
resolved before accepting more messages. New acknowledges the problem
of acquiring domains as means to side-step an accreditation system and
would be equivalent to your 'C' rating. A recipient may 'slow path'
such a domain to limit potential damage.
Add to this, the BCP affiliation level:
None '-'
Level 'A'
Level 'B'
Level 'C'
I agree that what this means is yet to be defined and would not be a
product of this work group, but it seems rather easy to define the
mechanism and have it in place.
I am not trying to get ahead,
There's no WG chair to invoke BCP 83: we can go ahead and talk about
most anything -- until we're chartered...
but it is hard to know how to keep this as simple as possible and yet
allow reasonable deployment in a non-disruptive way.
Indeed, it's hard. But it seems worth an effort.
The term "basic accreditation rating" should read "basic accreditation
information" as rating and accreditation seem at odds.
I agree that "basic accreditation rating" seems a poor term.
It seems my biggest disagreement with SPF and Sender-ID has been the
lack of consideration given to the potential liabilities and the
resulting consequences. This type of change from a rating to what may
be called 'state' offers basically the same information, but in a much
safer manner.
-Doug