spf-discuss
[Top] [All Lists]

Re: lookups by macro expansion

2003-10-31 07:37:28
On Tue, Oct 28, 2003 at 10:03:31AM -0600, wayne wrote:
| 
| I would recommend defining the existing methods as aliases for the
| lookup: method.
| 
| Defining the as aliases will serve several purposes:
| 
| 1) It makes the SPF config TXT record shorter, something which I think
|    Is A Good Thing.
| 

The strategic goal of SPF is fast widespread adoption.

Accordingly, SPF optimizes for simplicity of installation and
configuration.  I have identified three constituencies:
1) the lay DNS admin who will publish SPF records,
2) the lay postmaster who will install an SPF-capable MTA/plugin,
3) the developer community responsible for writing the SPF clients.

Sometimes the syntax finds itself caught in a tug-of-war between (1) and
(3).  What makes things easier for (1) often makes things harder for (3)
and vice versa.

Because (3) is a smaller community than (1), and more technically
skilled, I believe it is consistent with the strategic goal to shift the
burden from (1) to (3) wherever possible.

As Krug says, "don't make me think!"  People will want to implement SPF
without spending any more time than necessary to figure it out.

If we move to only a macro language, people will effectively be required
to review all the macros before they can get started.  This is a burden.

I see the "user guide to spf" as being:

novice:
  a
  a:domain.com
  mx
  mx:domain.com
  ptr:domain.com

80% of people can stop at this point and implement useful records.

intermediate:
  a/24
  mx/24
  include
  ip4:192.0.2.0/24

80% of the rest can stop here.

advanced:
  rhs
  ptrhs
  a:macros

this should satisfy everybody else.

you would use the macros if you had a custom DNS server that could grok
queries like

  -ip-.192-0-2-1.-localpart-.-idn.joebob.-envdomain-.domain.com._spf.domain.com

i think it would be a burden to ask ordinary dns admins to learn the
macro language unless they absolutely have to; that's why i think it'll
be better for adoption to leave in the rhs and ptrhs mechanisms even
though they could theoretically be constructed using macros.

the pi and localpart mechanisms can go into the macro language.

how does that sound to people?  especially people who've implemented PI
entries and would be affected by this change.

the regular a record remains a special case of the macro syntax, where
no macros are actually used.

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.txt
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡


<Prev in Thread] Current Thread [Next in Thread>