Re: Re: Draft ammendments on DNS lookup limits

> > > > 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.
> >
> > Radu.
> 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
> good idea.
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.
Thanks,
Radu.

-------
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

radu.vcf
Description: Vcard