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.
In the experiments with SPF, this was paid attention to. Even complex
records don't pose much burden.
15 MX records, plus a PTR record in SPF results in:
1 query for the SPF record
1 query for the MX list
15 queries for A records for the MXes
1 query for the PTR for the connecting IP
1 query for the A of the result of the PTR lookup
assuming 40 bytes for each domain label (a reasonable average, I think),
and an overhead of 40 bytes per packet and another 40 in the response, and
assuming a large SPF record, that's
1 * (40 + 40 + 40 + 200) +
1 * (8 + 40 + 40 + (15 * 8)) +
15 * (40 + 40 + 40 + 8) +
1 * (8 + 40 + 40 + 40) +
1 * (40 + 40 + 40 + 8)
2704 bytes. That's 19 round-trips, but parallelizable to 3.
According to my corpus of mail, that's insignificant amounts of data
transfer, especially considering that some 70% of my mail would
currently fail an SPF check were its domain owners to publish reasonable
records. In the short term, it makes a lot of sense.
In the long term, I think it's acceptable.
Computationally, as opposed to network load, SPF checking is pretty
easy. The libspf-alt package can handle an absolutely amazing number of
queries per second, and even the perl module can do quite a bit.
Ari