The way I look at this, a sender MUST NOT be given a right to
impose arbitrarily large computational loads on receiving MTAs: if
anything, it should be the other way around.
This question came up in the LMAP discussion, and I concocted my FSV
version of LMAP to suggest how to design a scheme that meets the needs
of the mail servers that are going to be LMAP clients. The FSV draft
is available as
http://www.ietf.org/internet-drafts/draft-levine-fsv-01.txt
First, since LMAP is a mapping from domains to IP addresses, FSV cuts
out the middleman and only publishes IP addresses and (as a concession
to save space) CIDR ranges. Domain managers are free to create their
list of IP's any way they want, but that's not our problem.
Second, I realized that MTAs are built in two different ways that
prefer two different kinds of DNS lookups. Some MTAs, like MS
Exchange, are a single long running program that has a lot of internal
threads handling SMTP sessions. Those MTAs want to slurp up all of
the LMAP info for a domain at once and then use it for the life of the
MTA to validate many SMTP sessions. The slurped record may be big,
but that's OK because it'll be amortized over many requests.
Other MTAs, including most Unix MTAs, fork a process for each SMTP
session. Each session will only look up a single IP for a single
domain, and then discard the info. In that case, the faster and
simpler the lookup is, the better, and any caching will happen in the
local DNS cache, not in the MTA.
I took a very simple approach in FSV, and publish all of the info
twice. For the big slurp, there's a potentially large "block" TXT
record with a list of IP addresses and CIDR ranges. For the
individual requests, there's "factored" records with the domain and IP
encoded into the record name and the data being an A record that
either exists or not, sort of like a DNSBL. (Students of LMAP will
recognize the block record as pared down from SPF and RMX, while the
factored records are ripped off from DMP.)
I'm not claiming that this is the only perfect way to build an LMAP or
MARID system, but I do claim that it does a good job of addressing the
needs of people who are likely to use LMAP or MARID data while
remaining implementable for data publishers, and the spec is whole lot
simpler than most of the alternatives.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
http://www.taugh.com