ietf-mxcomp
[Top] [All Lists]

Re: DNA

2005-07-24 11:10:44

On Sun, 2005-07-24 at 10:23 -0700, Dave Crocker wrote:
 but on the other hand it's specifically tailored to client SMTP
 ("_VOUCH._SMTP" etc.).  the EHLO domain name can be chosen relatively
 arbitrarily, and you should be careful not to claim that reputable use
 of the EHLO name extends to other services.

that might be why the _vouch qualifies (is specifically linked to) _smtp.

yes, but it doesn't link it to EHLO.  there are other identities which
can be used to for SMTP clients.  if there isn't, why did you object
when I implied CSV-DNA only can be used with CSV-CSA?

 if DNA can be applied to identities
 established with mechanisms other than the implied CSV-CSA, this MUST in
 my humble opinion be tagged in the accreditation record with a service
 different from "MARID", and as such the interpration will be out of
 scope for the CSV-DNA specification.  we do not want to (potentially)
 repeat the MAIL FROM vs. PRA mistake, do we?

I've read this paragraph several times.  I am simply not understanding it.  
At 
the least, I have no idea what the reference to tagging with a service 
different 
from marid means.

since I clearly isn't very good at explaining myself, let's start with
first principles.  we have an domain name which is authenticated somehow
whose reputation we want to check.  we look up PTR records, and as per
CSV-DNA, these begin with "_vouch._smtp".  at this point, we know the
pointers should link to CSV-DNA compliant reputation services.  we do
not know whether the name space of our authenticated domain name matches
the name space of identities employed by the reputation service.  this
name space must be declared in the TXT RR, and it's the very first field
in a record.  the draft uses the term "service" rather than  "name
space", however.  draft -02 says the service name MUST be "MARID", but
it does not identify the name space used.  being part of the CSV suite,
it is natural to ASSUME the CSV-CSA name space is used, but as far as I
can tell, the specification is entirely silent on this subject.

now, you were claiming CSV-DNA could be used with other mechanisms, and
therefore name spaces, than CSV-CSA:  "I would hope that reputation
services accessed with CSV's DNA are not "for" CSV."

I don't think that is true with -02 of the draft, since those
accreditation records necessarily would have to break a MUST, namely the
name of the service, or else risk misinterpretation of the record.

avoiding this problem is easy, the accreditation records should include
a fixed word identifier as a preamble (say "DNA"), so that it is clear
that
    DNA,MARID,1,A
and
    DNA,MX,1,A
both should be handled with the semantics of CSV-DNA (the "MX" name
space is just an example and at this time unspecified).  the current
alternative is
    MARID,1,A
and
    MX,1,A
leaving the latter completely undefined, requiring its specification to
copy elements from the CSV-DNA document rather than just build upon it.

(the service name "MARID" is not appropriate, btw, it really should be
"CSA" to avoid unnecessary confusion.)

 the scenario was that a domain owner had chosen an e-mail provider with
 bad reputation for its MTA name.  if the domain owner switches e-mail
 provider, the new provider's MTA name will be completely independent,
 and the domain owner's sent e-mail will instaneously be rid of the bad
 reputation.

That's why the helo/ehlo name is associated with the MTA operator.  Your 
phrasing suggests that the "domain owner" is somehow separate from the "email 
provider", whereas the ehlo name IS the email provider.

I don't think it's worthwhile to try explain this further, I suggest you
just go back and read the thread rather than have me rehash it here.
-- 
Kjetil T.


<Prev in Thread] Current Thread [Next in Thread>