spf-discuss
[Top] [All Lists]

Re: Standard Authentication Query

2005-03-29 13:37:33
At 02:46 PM 3/29/2005 -0500, Mark wrote:

On Tue, Mar 29, 2005 at 12:25:24PM -0700, David MacQuigg wrote:
>
> Also, I suspect the guardians of DNS at the IETF will be unhappy
> that no changes were made to address their concerns.

Given that there have been extensive discussions with DNS folks
over the years, can you provide links to actual concerns that
they have voiced that continue to not be addressed and that you
think should be addressed?

I'm just going by what I have read on this list. As I understand it, the objections to SPF at the vote on the last draft had to do with DNS loading. If we can address those concerns by something as simple as adding a modifier that doesn't break anything, I would say go for it.

I don't usually like "adding features" in a situation like this, but I think of masks as a counter to some features that were added without much thought as to abuse. The purpose is not to add new conveniences, but limit abuse.

> A typical top record might look like this one for rr.com:
> v=spf1
> m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24, > 65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
> -all

I could have sworn that the last few times this came up that
"ip4:1.2.3/24" was valid syntax.  I now see that the phrasing "It is not
permitted to omit parts of the IP address instead of using CIDR
notations.  That is, use 10.23.45.0/24 instead of 10.23.45." still means
that it's not completely clear whether or not "ip4:1.2.3/24" is valid.

I think Radu addressed this point yesterday. As I understand it, we are free to define any syntax we want within the string on the right side of m=. Maybe to avoid confusion we should write the compact notation as 24~24.30.203.

--Dave

************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************ *