Re: DNA

   I feel this deserves a reply, though I don't know exactly what to say:

Kjetil Torgrim Homme <[email protected]> wrote:
> On Sun, 2005-07-24 at 11:39 -0700, Dave Crocker wrote:
>> 
>> I think that you are confusing the semantics with the mechanism. 
>> DNA provides a mechanism for reporting some information.  The
>> semantics exist outside the mechanism.
> 
> 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.

>> 1. The client-smtp reputation/accreditation assessment that is
>>    associated with a particular domain name exists in its own right,
>>    independent of the mechanism used (eg, DNA) to report it.
> 
> there is no single correct definition of "domain name",

   Actually, DNS defines it quite exactly. That is the context here.

> 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.

> declaring that _any_ method of authentication is equally valid is
> a recipe for disaster. 

   I can't think of anyplace that has been declared.

> 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.

   (There is some ongoing discussion about recommending temporary
errors, but it's unlikely to reach consensus. OTOH, there is consensus
that _reputation_ services should have a way to recommend temporary
errors and/or greylisting.)

>> 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.

>> You are suggesting that the assessment information be labeled
>> according to the mechanism used to communicate it.  That's not a
>> good idea.
>> 
>> The assessment does not depend on the reporting mechanism.  The
>> assessment information certainly *does* need to be careful in the
>> way it specifies the identity and labeling what is being assessed,
>> but it should not specify how it is reported.
> 
> 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.

   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.

--
John Leslie <[email protected]>