ietf
[Top] [All Lists]

Re: SPF PTR Support [was SPF isn't going to change]

2013-08-24 19:26:01
On Saturday, August 24, 2013 13:10:09 Hector Santos wrote:
Scott Kitterman wrote:
Hector Santos <hsantos(_at_)isdg(_dot_)net> wrote:
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.

That's not correct.  PTR is not removed from the protocol, so
software support shouldn't change.

I believe I stated deprecate above which is the current draft
recommendations for not recommending PTR publishing in SPF records.
Is this still incorrect?

I don't run an SPF wizard.

I thought you managed this SPF wizard at http://openspf.org/tools ??
You don't? Ok I see it was taking down. Ok, sorry, well, you know what
I mean - it did have the PTR publishing as part of a natural default
setup and if not all the SPF wizards did as well. Is that not correct?

It did.  That's part of why it was taken down.  It made poor recommendations 
and several people finally concluded having nothing was better than continuing 
to provide that one.

It's not just about overhead.

So why was PTR deprecated?

See http://tools.ietf.org/wg/spfbis/trac/ticket/27 and the ML archives.  The 
ticket can give you an idea of the time frame to look in the archives.  Note 
that the final language doesn't use the word "deprecated". 

--
HLS

PS: I am not trying to change anything about the PTR 4408BIS status.
Just pointing out that a change was made that does touch base with
operations and thus not supporting (or delaying, forever) this part of
4408BIS is highly possible.

You might change what you recommend people publish, but nothing in 4408bis 
should affect the code related to PTR.  

Scott K