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 enginnering discussion outside MAPS.
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.
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.
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.
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".
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.
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.
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.
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.
(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. :^(
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.
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.
--
John Leslie <john(_at_)jlc(_dot_)net>