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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Scott Kitterman wrote:

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.

True, I was among the group of WG participants who felt a full PTR deprecation would be incorrect. As it was originally drafted, new SPFBIS parsers did not need to code the rDNS logic.

draft-ietf-spfbis-4408bis-00:

   5.5.  "ptr"
   ...
   This mechanism is deprecated and SHOULD NOT be used.


After debates, updated to draft-ietf-spfbis-4408bis-15:

   5.5.  "ptr" (do not use)
   ...
   This mechanism SHOULD NOT be used.  See below for discussion.

After more debates, finally changed by rev 15 as it stands now with draft-ietf-spfbis-4408bis-19:

   5.5   "ptr" (do not use)
   ...
   This mechanism SHOULD NOT be published.  See below for discussion.

With other text in the spec codifying it MUST be part of the processor, I think its fine. But it could still can give new future readers/developers of SPF parsers the idea that it doesn't need to parsed. Just consider relaxed policies are still accepted messages. Decreasing amount of records seen with a PTR with anything less than a -ALL policy could provide optimizing material to punk on the PTR processing. Just saying.

--
HLS






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]