Re: Re: More about the SPF RRTYPE

On Wed, Aug 17, 2011 at 10:18 PM, Alex van den Bogaerdt
<[email protected]> wrote:
>
> TXT records with an _spf prefix is clearly a better approach than TXT
> records without this prefix. That does IMHO not mean it is also a better
> approach than using SPF RR. I am not necessarily saying the opposite is
> true either(!)
>
> I think a very important lesson learnt should be: no "SHOULD", no choosing
> between TXT and SPF. At least not when the only difference is the type of
> RR. Why work on supporting SPF records when you can tell your customer
> "just use TXT records".
>
> Another important lesson learnt: It is good to have a major player
> supporting the protocol. But it has to be our protocol, not a derivative
> using the same encoding but with different semantics. I am not opposed to
> try again and integrate both experiments into one, but I do fear another
> episode of two slightly incompatible protocols where one ABuses the
> efforts of the other.
>
> The experiment could enter a new phase. There is no need for ASCII
> characters in the SPF record. This means that for instance
> "ip4:192.168.234.123" could be encoded in 5 octets instead of 19 plus 1
> for a separating space. There could/should be a "home base" modifier, so
> that repetitive domain parts or network numbers only have to be specified
> once. I mean: in network 192.168.100.0/24 authorize hosts 1,5,100 and 200.
> Under domain name subdomain.example.com authorize hosts alpha bravo and
> delta. Obviously such a "home base" should result in shorter notation,
> else the "old notation" is the better. The policy is evaluated left to
> right, a new home base setting will be applied only for partial entries
> following this home base. The default home base will be the domain being
> queried, and the network {to be discussed}.
>
> The use of PTR, and possibly MX, should IMHO be depriciated. More
> generally speaking: the effect of SPF on DNS usage should be evaluated and
> the protocol should, where necessary, be adapted.
>
> Participants in the next leg of the experiment MUST support v=spf1
> policies, encoded in either SPF records or in TXT records. They MUST also
> support v=spf2012 encoded in SPF records. If they choose to also _publish_
> a v=spf1 policy, then they MUST add the modifier "spf2012=preferred"
> unless this would cause their v=spf1 policy to become too big.
>
> I'm sure there's more to discuss for those who are interested, and I am
> also sure some will find my proposal utterly useless. Let's talk.
>
> my 2c
> Alex
>
>

Set aside the specifics you propose, I don't see the next go around as
an "experiment". We should be looking at an effort that is standards
track rather than experimental.

As far as a the religious wars that were MARID, I have a feeling that
if we stay tightly focused on cleaning up what we have already we can
avoid that.