Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
Yes I know it's too early to discuss DNA, but ideas don't arrive
according to a timetable :-)
It's never too early. ;^)
At the moment accreditation and reputation lookup keys in DNA take the
simple form of <HELO name>.<DNA service>.
Actually, DNA does not specify the format of a reputation lookup. I
expect the same format as _is_ specified for accreditation lookups to
sometimes be used, but there are several other formats with promise to
become popular.
I think it would be useful to make them more elaborate: <HELO>.<reversed
addr>.<IP version>.<service>.
For accreditation lookups, I don't agree. Anything which makes for
potential race conditions as domains change their server configurations
strikes me as a bad idea. Also, we should try to keep accrediation a
lightweight service (so that it indeed can be "free-with-boxtop").
For reputation, there are benefits from this elaboration. Indeed,
if we were facing the SPF situation, I'd consider this sort of thing
essential.
But CSA is pretty simple, and a single SRV query will usually establish
both authentication and authorization, in which case the extra traffic
to query and retrieve IP addresses seems pointless.
For example:
ppsw-0.csi.cam.ac.uk.130.8.111.131.ip4.blacklist.example
sesame.csx.cam.ac.uk.a.8.5.a.9.0.e.f.f.f.c.0.e.0.2.0.0.8.0.8.0.0.2.0.0.6.3.0.1.0.0.2.ip6.blacklist.example
This would allow some interesting services to be implemented, for example:
* It can be used for IP-based and/or HELO-based listings.
Sounds kludgy...
* The DNA service can implement CSA on behalf of the SMTP receiver.
We _may_ discover cases where it will prove necessary for servers to
"outsource" this function; though we don't yet know of any. I _don't_
believe that services which implement CSA can be offered on a large scale
without needing to charge.
* The DNA service can implement non-CSA authentication of the SMTP client
for legacy sites.
(I really don't think it would be a DNA service in that case...)
I agree that folks _will_ need to evaluate sites which don't publish
CSA records; and it's quite plausible that querying on both EHLO string
and IP address could prove helpful. But I see little or no overlap with
the charter of this group.
* The DNA service can combine multiple functions into a single
query/response exchange from the SMTP server.
That is certainly true.
SMTP servers are often based on many short-lived processes, which aren't
effective at cacheing DNS information. This could significantly reduce the
amount of DNS traffic generated by the SMTP server.
Unless you find a way to bypass the multiple blacklist checks which are
now done, I really don't see a "significant" reduction in traffic. Keep
in mind that multiple blacklist checks are done now quite specifically to
avoid depending on a single source; and it's hard to imagine a reputation
service which could do all you're looking for AND satisfy its users that
there's no need for diversity.
The disadvantage of this idea is that the lookup key will often contain
redundant information, which could cause DNS caches to be clogged up with
multiple names where only one is needed.
DNS cacheing is not magic. It depends (for efficiency) upon the
repetition of the same lookup strings, and its capacity is hampered by
overlong queries and/or responses.
Bottom line: If you think you can make money offering such a service,
go for it!
--
John Leslie <john(_at_)jlc(_dot_)net>