(Second try: I'm trying to adjust myself to Paris time; it's not
working well ;^)
It seems to me this discussion belongs on the CLEAR mailing-list:
Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> wrote:
On Tue, 2005-07-26 at 18:31 -0400, John Leslie wrote:
"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.
The MARID Working Group has been closed. That doesn't automatically
make references to it obsolete; however, it does suggest that there
might be a more appropriate string to tag the DNA accreditation TXT RR.
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.
"How it is done" doesn't covey much (to me, anyway). It's really
just a validity check, anyway, since the position of the TXT record
in DNS basically defines its meaning. And, as I said, the exact meaning
must be assigned by the accrediting organization.
(Recall that CSA completely answers the question of whether the
sending SMTP client is authorized by the domain cited in the HELO: the
question addressed by accreditation is whether that domain has policies
and practices which "adequately" protect against abusive emails being
sent.)
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).
Someone else is going to have to weigh in here: I don't understand
Kjetil's point, so I can't propose text.
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.
Quite the contrary: only the accreditation service _can_ say what
service it has evaluated. The expectation in DNA is that the operation
of a sending SMTP client is being evaluated; but DNA cannot enforce it.
It is up to reputation services to determine whether the evaluation by
each accreditation service is useful for its purposes.
Where the domain-name may have been found is quite immaterial. DNA
states that the HELO string shall be treated as identification of the
management of the SMTP client which sends it, subject to verification
through DNS lookup of SRV records that the domain in question authorizes
a client at that IP address to claim that association.
But for purposes of accreditation, the service doing accreditation
is expected only to accredit the policies and practices of the
management. If it is asked about a name obtained some other way, it
cannot be aware of how that name was obtained.
We are well aware that accreditation/reputation issues arise for
the various flavors of SPF: the DNA spec does not intend to make any
statement about how such accreditation/reputation issues might be
handled.
(IMHO, if there is an issue to be raised of confusion with SPF
reputation, it sits with the "_VOUCH._SMTP" substring in the PTR lookup,
not with the tag string of the accreditation record itself. And I'm
prepared to defend the "_VOUCH.-SMTP" choice, since the SMTP protocol
covers transport, not message content.)
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.
I entirely agree. (You make my point, I think...)
(It is possible that something within the text of Section 4 of the
DNA spec is confusing folks here. I will point out that the "_VOUCH._SMTP"
substring of the Target clarifies that the PTR record in question is to
recommend an accreditation service to check for DNA purposes, and that
other PTR records may also exist at the same position in the DNS tree.
DNA does not require that any actual query be done to that Target string,
but such a query would be expected to aid a in finding the explanation
of what is being accredited.)
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.
I fail to see how we could "give" or "take away" such a capability.
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.
Someone else will have to propose text to make this more explicit.
(Dave can speak for himself if he disagrees with anything I've posted.)
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 meaning of the accreditation record is delineated by its position
in the DNS tree, not its introductory tag.
the fix is simple: introduce a name space identifier to the
accreditation record.
I can't imagine any way to define such a "name space identifier"
which would do the job half as well as its position in the DNS tree.
Nor, IMHO, should we make any pretense we can do so.
--
John Leslie <john(_at_)jlc(_dot_)net>