Subject: [spfbis] Revisit: Issue #38: Deprecated

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 21:27:15 -0800

I think we could stand to get rid of the definition we have for
"Deprecated" in Section 1, but still leave the notations elsewhere in the
document.

Operationally, we have to continue to support ptr and %p because people are
using them.  That means compliant implementations still implement them.
We're basically stuck with it.  The right thing to do is what's done in the
"ptr" description that explains why we don't like it anymore.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Feb 2013 02:19:32 -0500

> "ptr" description that explains why we don't like it anymore.

Done.  Thanks.

Scott K

---

From: Commerco WebMaster <[email-masked]>
Date: Wed, 06 Feb 2013 01:38:31 -0700

Murray,

I have never cared to use the PTR syntax for many of the reasons already 
exhaustively covered in the most recent threads and then some.

I am far more happy to use the IP4 syntax instead, as it does not depend 
upon the "kindness" (read responsiveness or willingness to adjust PTR 
record) of the IP address provider.  My own experience with this has 
never been problematic, however there are documented cases where ISPs 
can be very difficult to work with on getting PTRs changed for whatever 
reasons.  Also, in the 8 or so years that we have implemented SPF around 
here, as I recall, the IP4 record entries have only had to change once 
(perhaps twice).

For smaller company implementations, using IP4 works great, as there are 
only going to be a few individual IP addresses for the approved sending 
MTAs.

For larger company implementations, using IP4 works great (with a CIDR 
range), as the representation of the publisher is that the mail is 
coming from an MTA within their network.  While less granular, the 
security seen in larger environments will be presumably better than that 
of smaller environments.  Perhaps larger environments are also better 
suited to deal with a lack of granularity necessitated by using a CIDR 
range rather than an individual IP address (e.g., hopefully their 
network does not get hacked and a bogus MTA is established somewhere in 
the approved IP space within the CIDR range).  Of course, those kinds of 
discussions are probably well beyond the scope of SPFbis.

While there are obviously some good reasons to want to implement PTR (as 
some folks do this today in their TXT records), for many environments, 
it is simply not a feature of SPF needed in their TXT records.

In my own view, PTR could be depreciated, however as doing so would 
result in breaking existing implementations without a show stopping 
reason to do so, perhaps simply advising against using PTR in TXT 
records may be best.

Best,

Alan M

On 2/5/2013 10:27 PM, Murray S. Kucherawy wrote:
> "Deprecated" in Section 1, but still leave the notations elsewhere in
> the document.
>
> Operationally, we have to continue to support ptr and %p because people
> are using them.  That means compliant implementations still implement
> them.  We're basically stuck with it.  The right thing to do is what's
> done in the "ptr" description that explains why we don't like it anymore.
>
> -MSK
>
>
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>