>> One of the points of "deprecation" is that we don't eliminate it >> entirely, but say that it's no longer used. New implementations no >> longer generate it, but implementations that are interested in >> backward compatibility will still include support for it on receipt. >> >> Eventually, when we see that its use is rare enough, the community >> might move to no longer include support (no longer needing backward >> compatibility). But I expect that support on receipt would remain for >> some time. > > As soon as we say deprecated, the justifications for backwards > compatibility become tenuous. If a sender has no reasonable > expectation that most validators will respect their request, why would > they make such a request (other than in ignorance). I think very few > would argue that using percent is a long term strategy for any given > domain. Either percent is useful or it is not.
I don't understand what you're objecting to: the whole point of deprecation is to tell the sender not to make the request. Backward compatibility is purely on the receiver -- are there still enough old senders who haven't updated their software, such that it's worth supporting PCT if I receive it... or are the consequences of my ignoring it such that it doesn't matter? That's up to the judgment of the receivers. If we deprecate it, compliant senders will simply stop sending it. Which is what it seems that we want. Barry _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
