FWIW I believe that Radu Hociung has made it abundantly clear that
indiscriminate inclusion of policy from outside one's sphere of
influence is largely a fool's errand. Flattening has little to do
with the folly.
And yet he insists that I must do that to conform to his version of a
reasonable number of DNS queries.
No, I never did that... Please find where I said it's ok to flatten
across administrative boundaries. I showed that it _could_ be done to
temporarily alleviate an expensive record outside your control. The
other reason I showed it is to make the point the the spfcompiler SHOULD
and DOES make the difference between compiling, and flattening, and that
it does respect the boundaries of administrative control if you don't
force it to -flatten.
I also said that there are still bugs in it, so it's current output may
not be 100% correct.
And I did give you the compiled record (without -flatten) as well.
I did say that it should be strongly recommended (I believe I used the
termed smacked) that your ISP reduce their 11 lookup list of A
mechanisms down to a list of 10 IP's.
When I say that 10 is too few because of ... and your answer is that 10 is
fine because I can publish a record that turns the included record into ip
addresses, how else am I to interpret that.
This is how you should interpret it. Has anyone else interpreted what I
said like Scott did? I apologize if my language is unclear at time.
A limit of 10 is fine, because you should smack your ISP
(megapathdsl.net) to publish a less expensive record, and then, your
include:megapathdsl.net mechanism will only cost 1 TXT query, instead of
the 11 or so queries it requires now.
I have stipulated that ISPs should always publish cheap records, because
they HAVE CONTROL OF THEIR SERVERS. They rarely rely on the services of
other domains. That's why they are ISP. Just the way aol.com and
earthlink.net have figured it out, maybe your ISP can too. I'm willing
to bet that they will see the light. Eventually.
It boggles my mind that you provide help on spf-help, yet you cannot
help your own ISP understand what SPF is about. I understand that _you_
would have to offer the help, instead of waiting for them to ask.
As I've said in another post, we COULD deprecate all the mechanisms except
ip4 and ip6 and then give RMX another try, but I don't think it would be a
This idea is entirely yours, I never alluded to anything like that, with
the exception of suggesting that maybe the mx mechanism is not as useful
as it first appeared. I don't think I even suggested that it be removed.
I said I might support such an initiative.
You can't have it both ways, either the limit has to be high enough to
support including complex policies that currently exist because flattening
across administrative boundaries is a bad idea or your limit is OK and
flattening across administrative boundaries is OK too.
Which do you want?
I prefer if you read what I say a second time before replying. Perhaps
try to understand what I mean.
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com