Andy Newton suggested I start a thread on the balance between ease
of sender advertising and the receiver computing load. Here's my
attempt...
I find it worrysome that we're proposing things like
"v=spf1 mx -all"
meaning that the receiving MTA is expected to pull the entire list of
MX records, resolve them to IP addresses, and check whether the one
IP address of interest is in that set.
This could be more computational (and network) load than just
receiving the message.
Similarly I find it worrysome that the "30% solution" expects the
receiving MTA to pull an arbitrary-length list of MARID records,
resolve them to addresses and/or address ranges, compile these into
two sets, and check whether the one IP address of interest is in
either set.
While I don't argue the importance of ensuring the ease of
advertising MARID records, that should be a one-time event, while
receiver check is a per-email event. To me, that's a strong
argument for optimizing to minimize the computational load of
lookup events. The task of parsing "ease-of-advertising" strings
into DNS records could be automated with a PERL script.
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.
I don't believe we need to throw out either SPF or the "30%
solution" because of this, but I strongly urge that we work them
over so as to minimize the receiver's computation load.
--
John Leslie <john(_at_)jlc(_dot_)net>