At 20:09 23/08/2004, Jim Lyon wrote:
I believe that the latest Protocol draft (draft-ietf-marid-protocol-03)
contains changes that don't correctly reflect the consensus of the group
concerning DNS record types. Briefly, it states:
1. Publishers MUST publish using the new SPF2 record type.
2. Publishers MAY also publish using TXT records.
3. Consumers MUST do lookups using the new SPF2 record type.
4. Consumers MAY also do lookups using TXT records.
5. Consumers MAY do both lookups (3 and 4) in parallel.
6. If consumers receive records from both lookups, they SHOULD use
the SPF2 record and ignore the TXT record.
These are all in section 2.1.1 of the Protocol doc.
The problems with the above are:
a. It's not what was previously debated / agreed to.
b. Anyone who can't publish an SPF2 record cannot comply with this spec.
c. Anyone who can't look up an SPF2 record cannot comply with this spec.
d. Publishers who take the "MAY" in step 2 above to heart and don't
publish TXT records will have their record be completely invisible
to consumers that can't query for the new record type.
Standards documents are supposed to be long lived, and everyone
knows there is going to be a period during which b. and c. are facts
of life. The question is how to overcome that hurdle in the shortest
time possible.
In my dealings with operational people the only thing that will
get them to upgrade is clear violation of standards, "MUST" or "MUST NOT"
violation. "SHOULD" "SHOULD NOT" "MAY" are brushed under the table
or join the long queue of things to fix when time is available.
For this reason I pushed for the strong text in the draft.
Your point d. is a good one but still runs counter to the philosophy
above as when SPF (I do not like the name SPF2) RR has died or become
prevalent there is no reason publish spf policies in TXT records.
As for a. is concerned I can not find an statement from chairs
that is the consensus of the working group. One of the reasons that Mark
agreed to the text was exactly to find out if a rough consensus on this
issue could be formed.
I respectfully request that the above requirements be replaced with:
1.Pushblishers SHOULD publish using the new SPF2 record type,
if they are able to do so.
This is an operational guidance not a definition of a standard.
If this text is accepted by the WG then none has to ever deploy
the new type.
2. Regardless of whether they published using the SPF2 record
type, publishers MUST publish a TXT record.
This is counter to a long term strategy and unless the WG intents to
be around for a long time there will never be a time when publishing
only SPF RR is acceptable.
2a.The contents of the SPF2 record and TXT record MUST be identical.
This I agree with and the current document says so (at least
that is my reading of section 2.1 paragraph 3).
But I agree with you that putting in a MUST there is a good idea.
3. Consumers SHOULD check for the new SPF2 record type, if they
are able to do so.
4. Consumers who either cannot query for SPF2 records or who find
that a domain hasn't published any SPF2 records MUST query for
a TXT record.
5. Consumers MAY do both lookups (3 and 4) in parallel.
6. If consumers receive records from both lookups, they SHOULD use
the SPF2 record and ignore the TXT record.
Brief Discussion:
It's undisputed that the world would be a better place if everyone uses
the new record type. However, it's also undisputed that many players
won't be able to publish and/or consume the new record type until new
software is installed. The updated requirements as I've spelled them out
above will me that:
a) Everyone can work before new DNS software is installed.
b) After new DNS software is installed, there will be minimal harm to
the DNS system.
The fundamental difference between your position and mine is
you: want everyone to be compliant at all times.
me: Specify clearly fully compliant state and tolerate non compliance
during phase-in.
I think that (a) is obvious. There are four sub-cases:
i. Publisher and consumer both have out-of-date DNS software:
If the publisher and consumer both have out-of-date DNS software, the
publisher will only publish a TXT record. The consumer will only query
for a TXT record, and get the right information. All of the oft-debated
issues of packet size and TCP fallback apply.
This is the stage we all are trying to keep to absolute minimum,
What the text in the ID is trying to do is to get as publishers to
publish SPF records as soon as possible, while giving the consumers
more flexibility in how the information is accessed:
via TXT or SPF records.
The issue we need to keep in mind is test and traceability.
It is simple and quick to check if a publisher is compliant,
thus the MUST's.
It is simple to check if a consumer MTA issues queries for SPF,
thus the MUST.
It is hard to check which type is used, if both are available thus
the SHOULD.
Once the records are available and consumers have
started to ask for them then it is publishers choice to either
continue to publish TXT records or risk failures when dealing with
the laggard consumers.
ii. Publisher has up-to-date DNS software and consumer has out-of-date
DNS software:
<snip>
iii. Publisher has out-of-date DNS software and consumer has up-to-date
DNS software:
<snip>
iv. Publisher and consumer both have up-to-date DNS software.
If both the publisher and the consumer have up-to-date DNS software, the
publisher will publish both an SPF2 and a TXT record. They consumer will
query for the SPF2 record, and get the right information. The
packet-size issues will generally not apply, because the SPF2 record
won't be mingled with other irrelevant records.
So in all four cases, the updated requirements work. Contrast this with
the currently specified requirements, which cause cases (ii) and (iii)
to fail to discover the record.
I humbly disagree, the ID documents the state everyone will (hopefully)
migrate to, in your analysis you assume the worst behavior possible by
both sides. For the publisher in the short term it is in their
interest to publish both RR types with spf information.
Similarly the consumer by asking for both types maximizes its chance of
getting an answer.
Once the MARID RR type has been in use for some time it is possible
to assess if it is worth while, then there are two optimizations possible:
cut out the TXT query from the MTA's
Tear out all the SPF processing from the MTA's.
At this point I do not know which one will be the one done, I hope it
is the first one.
In conclusion, I recommend the WG keep the text as is.
Olafur