Re: More about the SPF RRTYPE

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Murray S. Kucherawy 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 lot of people would be happy if SPFbis said to use an "_spf"
> TXT record, and the various open source and commercial implementations
> evolved to comply.  People could leave SPF TXT records in the current
> location for transition purposes as long as they like, but we should
> explicitly deprecate that practice and encourage the new one.

This would abandon the entire deployed base and would also cause 
implementations to do *yet another* lookup for policy discovery (in 
addition to domain./TXT and possibly domain./SPF).  I don't think there's 
any point in doing that for v=spf1.

If the IETF WG that's under discussion for this effort were to introduce 
*such* a change, I doubt that many SPF implementations would follow suit 
soon.  Everyone would probably just continue what they're doing and 
ignore 4408bis.

> > 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. [...]
>
> Some of this stuff might fly,

I don't think it would.  If a sysadmin has got two options: (1) follow 
4408bis and use new tools to create an obscure binary representation in 
TXT \123\456 format or (2) just type up your SPF record in human-readable 
format and ignore 4408bis, which are they going to do?

Besides, the binary format wouldn't fundamentally solve any problems.  
Merely ~doubling the maximum number of declarations in an SPF record is 
worth almost nothing.

- -Julian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk5O1x8ACgkQwL7PKlBZWjv5LQCfU1XYg3O/AfFq47Kcn/RT+Ca4
TowAoLOQM2246QCMeFOHtqOytHY28I+W
=fFCR
-----END PGP SIGNATURE-----