In message <42523d2d-85c6-4e6d-b2a7-6791a0e5d4a8@xxxxxxxxxxxxxxxxx>, Scott Kitt erman writes: > > > Mark Andrews <marka@xxxxxxx> wrote: > > > > >In message <6.2.5.6.2.20130505082013.0adbbe40@xxxxxxxxxxxxx>, S > >Moonesamy write > >s: > >> Hi Mark, > >> At 15:57 04-05-2013, Mark Andrews wrote: > >> >The publisher can choose to interoperate with everyone by publishing > >> >both. > >> > > >> >The client side can choose to interoperate with everyone by looking > >> >for both. > >> > > >> >Both side can choose their level of interoperability. There is no > >> >bug. > >> > >> Thanks for the feedback. > >> > >> Based on the quoted text I would write the text as: > >> > >> (i) you must have X and Y where X and Y are identical. > >> > >> (ii) I ask you for both X and Y (see [1] for example). > >> > >> Item (i) is a combination of the previous items (a) and (c). Item > >> (ii) is the last part of previous item (d). > > > >That was not the intent. Having choice here is very important here. > >In fact it is essential to reach the end goal of Y only when starting > >with X only. > > > >There is nothing wrong with failing to catch every possible forgery > >possible if both sides are using SPF. Unfortunately the SPF WG > >seem to think that unless the RFC does catch every possible forgery > >that it is broken. The SPF WG appears to not want to allow operators > >to have the choice. This is the case "pefect" being the enemy of > >"good enough". We need "good enough" here not "perfect". > > > >Mark > > If we publish a 4408bis that suggests the normal way to publish an SPF > record is in type SPF, then it'll get about 98% less effective based on > the data we've collected. What you are suggesting is more like 'ignore > the deployed base and start over'. That's not wgat the WG was chartered > to do. No one said "ignore deployed base". Firstly normal != only. Secondly one could quite easly add "fixup SPF" functionality to nameservers/zone signers by having the master server/signers add type SPF records if they are not present when there are v=spf1 TXT records. This would also require fixing some DNSSEC records but it is doable. Name servers/signers fixup DNSSEC records all the time. Adding another type of record to fixup is a relatively trivial change. For unsigned zones one could do this on slave servers as well. You have already mentions you have a script that does it. A script needs someone to install it and run it so it is not comparable, other than a proof of concept that it can be done, to getting nameservers to do the fixup. This get done installed and run automatically. Installation happens as part of OS upgrades / new server installs. It gets run as it is part of the default behaviour. > Additionally, I'm personally against publishing documents that require > special external knowledge (if 4408bis prefers SPF over TXT deployers > will have know to ignore that part of the RFC if they actually want the > protocol to be useful. To promote interoperability there has to be a MUST > publish and a MUST check format in common. Given the lack of type SPF > deployment, it's crazy to suggest that it should be the required type. What external knowledge. 4408 already effectly says that you need to publish SPF records. TXT records are described as "for backwards i compatibilty". It says you SHOULD publish both. You are worrying about it not been "perfect" when it was in fact what was in 4088 was "good enough". Mark > Scott K > > >> At 16:26 04-05-2013, Mark Andrews wrote: > >> >Additionally it supports all implementions from pre RFC 4088 through > >> >to the desired end state of type SPF only. > >> > > >> >B.T.W. the next point releases of named (at rc2 now) warns if SHOULD > >> >have both is not being done. > >> > >> Noted. > >> > >> Regards, > >> S. Moonesamy > >> > >> 1. http://www.ietf.org/mail-archive/web/ietf/current/msg79114.html > >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx