Earl Hood <earl(_at_)earlhood(_dot_)com> wrote:
The FAQ, <http://mipassoc.org/csv/csv-faq.htm>, has the following:
* Q: What does that look like in "bind" format?
* A: I advertise the DNS SRV as:
mailhost IN A <MTA IP address>
IN PTR _vouch._smtp.csv_vouch
_client._smtp.host.example.com SRV 1 2 0 host.example.com
Shouldn't the last line be,
_client._smtp.mailhost.example.com. SRV 1 2 0 mailhost.example.com.
Indeed it should (as the actual records at jlc.net show).
Another question about the FAQ: For the question "What will that
software now do?", it is mentioned that a DNA and CSA query are done
in parallel. However, how can the DNA be done unless the accreditation
service is already known?
A DNA query would be done to a reputation service chosen by the
receiving SMTP server. There is no need to know what accreditation
services might be recommended by the sending SMTP client.
If the server is going to use what the client published (a highly
questionable practice), the server would first have to do a
_vouch._smtp lookup first before doing an accreditation lookup.
There is little point in doing such a lookup unless you have some
means of knowing which accreditation services to trust. (Presumably
anyone running a reputation service would gather such information.)
I'm wondering of there is really any value for an SMTP client
to publish vouch records. In accreditation, the server cannot
trust anything provided by the client, therefore, the server should
already have a predefined set of accreditation services it will query,
regardless what an SMTP client may claim.
Yes, except we recommend queries to "reputation" services, which
are a somewhat different animal. Sending SMTP clients are unlikely
to seek accreditation from every service receiving SMTP servers might
trust.
The Security Considerations section of CSV-DNA should discuss this.
Feel free to suggest wording. (I'm not sure how many other readers
will think this belongs in "Security Considerations", though.)
Section 5 of CSV-DNA implies in step 3 that a server can query the
client's vouch record for determining accreditation services to query.
If this is the case, the FAQ does not reflect this scenario.
The FAQ is a personal document; and I personally have no enthusiasm
for the mechanism in Section 5 of DNA.
Since such behavior is questionable from a security standpoint,
should SMTP client publishing of vouch records even be supported?
Absolutely!
It's essential that sending SMTP clients have a standard way to
publish accreditations they have obtained. And it's essential that
all reputation services have a standard way to access accreditation
results.
Admittedly, the _interpretation_ of accreditation reports cannot
be standardized. And it is not. But evaluating the trustworthiness
of hundreds of accreditation services is a practical problem; while
evaluating the trustworthiness of hundreds of millions of domains
is not practical.
With a standard method of publishing accreditation reports, it
will be possible to recover from an episode of spamming through a
particular SMTP client. Without standardized access to accreditation
reports, recovery of reputation is essentially impossible.
(Yes, I know there are folks who think recovery _should_ be
impossible: they're free to contract with reputation services which
dismiss _all_ accreditation reports; the rest of us will be free
to choose more reasonable services.)
What is the value of an SMTP client publishing vouch records?
What real-world cases exist that an SMTP server will make use of
such records?
It's not clear whether SMTP servers _will_ make direct use, once
there are reputation services available to do this for them. But
don't rule out rumor mills -- they should spread the word pretty
quickly which accreditation service accredit something useful.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear