On Tue, 2005-07-26 at 18:31 -0400, John Leslie wrote:
I feel this deserves a reply, though I don't know exactly what to say:
Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> wrote:
okay, let's say "MARID" denotes "DNA", but that leaves no method of
declaring name space.
"MARID", you should recall, stands for "MTA Authorization Records
in DNS", which is exactly the subject of DNA. So "MARID" denotes the
subject matter; DNA specifies how the reporting is done.
okay, I thought "MARID" was dead and that references to it were
obsolete. in any case, I think it's better to use "how it is done" as
the tag, since the tag identifies exactly that for an implementation.
if you envision other methods later, it's prudent to change it to say
both "MARID" and "DNA". or just "DNA".
there is no single correct definition of "domain name",
Actually, DNS defines it quite exactly. That is the context here.
the draft does not say so. it is common usage to say "domain name"
about the name of the zone, and "host name" about entries in that zone.
I therefore think "domain name" should be explicitly defined (with a
reference to RFC 1034).
just look at the discussions here suggesting it can be determined
based on reverse DNS, MAIL FROM, PRA or EHLO, or any number of other
methods.
There are a number of fields which contain domain-names. The DNA
mechanism could in principle be applied to any of them. In fact, we
initially wrote DNA such that it could be widely applied; only later
did we limit it to the HELO field and CSV.
that's fine. the problem is that the accreditation service can't say
which are valid, or even which service it has evaluated. an SMTP client
can point to an accreditation service which validates web content on the
same domain name. "_VOUCH._SMTP" allows the client system to point to a
accreditation service specific to SMTP, and it could also add a
(hypothetical) "_VOUCH._HTTP" in cases where there's running a web
server on the same host. which of these records were used, is not known
to the accreditation service, it operates blind.
declaring that _any_ method of authentication is equally valid is
a recipe for disaster.
I can't think of anyplace that has been declared.
it has been declared by omission.
the accreditation record must declare stringently what it covers.
DNA has declared that as stringently as we believe appropriate.
Beyond that, it's up to each accreditation service to declare the
exact meaning of their accreditation.
then you need to give them the capability.
2. A particular client choose to declare itself associated with
that domain name. CSA is one way to make that declaration.
yes. when there are many methods, the client may choose to point
to a reputation service which has accrued reputation based on some
other name space.
In CSV, sending SMTP client domains point to _accreditation_ services.
The receiving SMTP server would be the party using reputation services.
We've tried to keep that distinction clear through the CSV specs.
sorry about the sloppy usage, but please explain the difference. the
word "reputation" is only used twice in the specs, and not in what
appears to be a terminology establishing context.
not the reporting mechanism per se, but the name space used is a
crucial part of the identity.
CSV-DNA must either be locked to CSV-CSA, or it must explicitly cater
for other name spaces.
DNA is locked to CSA, though a similar mechanism could easily cater
to other name-spaces.
Dave Crocker doesn't seem to agree with you, which to me clearly
indicates the spec needs to be more explicit on this point.
It might help to point out that in section 6 of the DNA spec, we
intended that in "Name: <domain being checked>.<Accreditation Service>"
"<Accreditation Service>" is not necessarily the name of the service
provider: if the same provider provides different accreditation services
they might well choose to use subdomains for different services. We
believe there is ample room for DNA-like mechanisms covering names
obtained from other sources than HELO strings. We do not believe there
is any need to limit how these might be specified and reported.
since the DNA spec disallows reuse of the spec with a different name
space (the record MUST say "MARID", and you now clarified "DNA is locked
to CSA"), I'd say it limits future usage significantly.
the fix is simple: introduce a name space identifier to the
accreditation record.
--
Kjetil T.