Looks to me like this thread has run its course. By way of chiming in with my
entirely redundant 2 cents:
Why not have one query produce a short list of IP blocks that are
authorized to act as mail servers for a domain? Then even a huge domain
like rr.com could give you hundreds of authorized IP servers in one
cacheable record.
The simple answer is that that's not the way the DNS works. It might be fine
to pursue such an enhancement to the DNS, but that's not the job of the CLEAR
work.
CSV lives with existing DNS conventions, as best it can. As Tony noted, the
SRV record format is actually quite well-suited to the task.
It is always appealing to seek enhancements to the underlying system, and
sometimes it is even necessary, but it always ensure delay and frequently
distracts from the main work.
Would it not be simpler to have one record list all the mail-serving IP
blocks for an entire domain?
It is rarely "simpler" to change a data storage model for a global
infrastructure service.
It seems like the choice now is between CSV with a large number of single-
server records, and SPF with far fewer records but the potential for abuse
of its whiz-bang features.
There are a number of ways CSV and SPF differ. Besides the fundamentally
different semantics -- which ought to obviate the need for further comparison
-- the comparison I prefer is about relative complexity. CSV is extremely
simple. SPF is extremely complicated.
It seems to me the fundamental advantage of CSV over SPF is that CSV
doesn't try to associate domain names with IP addresses outside of that
domain.
The fundamental advantage*S* are that:
a) CSV uses an identity related to direct, local MTA operations, rather than
referring back some unknown number of hops to a content author who has no
involvement in the operation of the MTA, and
b) CSV is simple. Extremely simple. It took an enormous amount of effort to
make it this simple...
THe focus on MTA operations ID is not a minor matter. One small example of te
benefit is that operations folk can focus on aggregate behavior, across many
messages and message authors. SPF is strictly focussed on per-message
behavior and does not provide a means of assessing aggregate MTA operations.
CSV got it right on how to handle forwarders. I think there is still a
ways to go on reducing the DNS load.
A CSV query typically takes one lookup. You want to assume certain query
patterns and then optimize for them, assuming that you can get the average
number of queries below one. Alas, you are trying to fix a problem that is
not assessed as a problem, relative to other issues.
In fact your focus seems to be on reducing certain administrative
requirements, namely creating one -- relatively stable -- record per name.
This isn't a real problem.
By contrast, the administrative problem of having to keep a running
correlation between all outbound MTAs and all message author domains is
downright onerous.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net