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