ietf
[Top] [All Lists]

Re: [dnsext] SPF isn't going to change, was Deprecating SPF

2013-08-24 11:40:47
Hector Santos wrote:
Phillip Hallam-Baker wrote:
Putting a statement in an RFC does not mean that the world will
automatically advance towards that particular end state.

Thats correct. No one is forced to support RFC 4408bis. From my perspective, there are four basic major changes to BIS - all optional:

  1 - Add Authentication-Result: 5322.header.
  2 - Relax SPF HardFail Policy rejections to Accept-Mark operations.
  3 - If 2 is perform, then add code to separate user failed messages.
  4 - Remove any support for SPF type99 queries and publishing.

For our SPF implementation, we never did #4 for lack of infrastructure readiness but are ready to support once the the backbone is ready for it. We will probably will do #1 for all non-HARDFAIL result but we won't do #2 because it will cause a high redesign cost with #3. Not performing #3 would be a major security loophole is you begin to support #2. Until we are ready to do #3 and close that security loophole, #2 won't happen.

I should add:

    5- Deprecate PTR by removing PTR publishing support

We won't advocate this because for our small to mid size market, this is the lowest cost setup for them - using a PTR. For all our domains, we use PTR as well. No need to change it. This is one of those "Set it and Forget it" SPF record setups. Using the PTR was the default arrangement for most small/mid operations provided by most if not all the SPF Web Wizards. This was removed in Scott's popular SPF wizard but not in other SPF wizards. Note: The overhead concerns are passe with the trend of SMTP receivers doing PTR lookups, thus any transaction SPF validator will not contribute to any PTR network overhead.

--
HLS