Hector Santos <hsantos@xxxxxxxx> wrote: >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. That's not correct. PTR is not removed from the protocol, so software support shouldn't change. I don't run an SPF wizard. It's not just about overhead. Scott K