Dave Crocker said:
in any event, i changed the latest draft to use the word 'list'
in place of the more specific terms.
-02 looks good! Moving DNA out a month makes sense. I encourage you to
edit on the wiki. I have applied your changes to the wiki. Dave, it'd
be helpful if you accept s/.MailFrom/.MAIL FROM/g! (MailFrom is a
WikiWord.)
On 10/1/2004 10:53 PM, John Leslie sent forth electrons to convey:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
<Doug's snipped>
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.
I strongly agree.
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.
I can't think of a better idea. Isn't the alternative a free-for-all?
Otherwise, I fear we'll spend more time disussing what topics to open
than we spend discussing them.
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.
Are you suggesting
s/blocklist/blacklist/ ?
I don't care either way.
I would also point out that many blacklists and blocklists can be
considered accreditation services:
the way such services are typically implemented, the lack of an entry
indicating a negative accreditation for an entity indicates that the
entity is accredited.
Doug's recent post shows he also wishes to use accreditation as a term
encompassing a lot.
However, one could argue that the plain meaning of accreditation
services does not include DNSBLs. One at first might claim that such
services would not appear in DNA records. However, I could see
responsible senders publishing a DNA record indicating accreditation by
an accreditation service that essentially mirrors an RHSBL, but in DNA
format, publishing a positive recommendation because it interprets the
lack of an entry as accreditation.
Normally, having a record or not having a record was the deciding
factor.
I would call even this a reputation service.
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.
True.
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.
Hence out of scope, but a good idea for a BCP later. Table?
....
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. :^(
Some employ lawyers, others may continue to use other methods to avoid
the problems the lawyers might help deal with.
I believe CLEAR should not tie one to the other, but I believe some
accreditation services can, should and will do so.
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.
I'd also like us to work on this (1).
I believe that my "Make CSV backwards compatible with legacy SPF
records" idea (2) is in scope with the charter as written, but my
draft-ietf-marid-spf3-00 draft (3) is not. Which is fine with me. Do
we have to edit the charter to make these (1,2) more clearly in scope?
E.g. add: "Discussion of related drafts for implementations codifying
extant ways to query authorizations, reputations or accreditations is in
scope."?
Dave, it sounds like you would prefer to see "Make CSV backwards
compatible with legacy SPF records" presented as a separate I-D, not as
proposed edits to CSA; is that right?
Also, s/Details (technical and policy)/Details (operational and
policy)/ may be in order. (or equivalent in latest draft text:
s/technical/operational )
Also, s/working group/Working Group/ may be in order.
There's no WG chair to invoke BCP 83: we can go ahead and talk about
most anything -- until we're chartered...
No, let's act as if the Charter is in affect.
I agree that "basic accreditation rating" seems a poor term.
Me three; changed on the wiki: *s/rating/recommendation.*
=-=-=-=-=-=
PS. Can/should this list's settings be configured to change headers so
replies go just to the list by default? I think so.
=-=-=-=-=-=
Glube said:
Needless to say Meng Weng Wong has invited individuals who
support SES to get involved with CLEAR.
I don't mind it being discussed to the extent that it fits the primary
goal: Compatible Low-overhead Email Authentication and Responsibility.
=-=-=-=-=-=
Regarding the meanings for A,B,C,D and E levels in the DNA draft: I
suggest we move away from specifying meaning, and instead provide more
than one set of sample meanings. For some accreditation services,
Doug's meanings wouldn't work well, though for others they'd be great.
Here's an example: I expect many folks willing to accept mail accredited
by a service that is fully automated, or provides ratings, without
stating that accreditation is provided or not provided.:
Domain first registered by: Degrees of separation to Elvey:
A '95 1
B '97 2
C '99 3
D '01 4
E unknown unknown
Another service, believing it would help in a lawsuit, might wish to not
make any explicitly negative statements, or wish to have a category for
entities that threatened to take it to court or for domains with ssl
certs...
By over-specifying the meanings, we would be specifically breaking
support for such services.