"Meng Weng Wong" retorted:
On Fri, Oct 29, 2004 at 03:23:28PM -0400, Michael Hammer wrote:
|
| It would appear to me that the outcome you negotiated with MS is to
| place the onus on the publisher of the SPF1 record to work around the
| failures of SenderID/PRA implementation to DTRT.
OK, let's run a thought experiment so we can think this
through.
Suppose we renegotiate and the agreement is that MS PRA stuff
will not use v=spf1 records for PRA scope checking. MS will
tell people to publish spf2.0/pra, and the SPF community
will tell people to publish v=spf1.
What will senders do?
Point taken (as least by me): so this creates a communications contest, and
guess who has more funding for communications.
So here is an alternative proposal to let Microsoft promote publication of spf1
records, yet not run the risk of fouling up SPF tests where their use in PRA was
not envisaged.
SPF should define (even at this late day) a new modifier for spf1: "pra" with a
single legal value "yes".
If this modifier is present in a record, then the publisher is inviting /
permitting her policy to be used in PRA tests.
For completeness, we should mandate that the modifier only applies to the record
in which it occurs. If a record contains "pra=yes" and an "include" is also used
in this record, PRA testing is NOT to be applied to the included record, unless
it itself also includes "pra=yes".
If "pra=yes" does not occur within the record, then PRA tests MUST NOT be done.
This condition we write into the spf experimental I-D.
If PRA implementers disrespect this prohibition than it will be clear to all
that they are intentionally breaking the mail system - which would create very
bad PR for them.
All SPF-compliant, pre-existing SPF implementations will just ignore the
presence of the new modifier.
Unless I've made a technical mistake somewhere, this scheme allows senders to
'opt-in' to dual use of their record, with no impact whatsoever on:
1) Pre-existing SPF records,
2) Those publishing new SPF records who do not wish to opt in to PRA
3) Existing SPF receiver test implementations.
Now Microsoft and the SPF community will both be promoting the publishing of
SPF-compatible records, without the danger of SPF record abuse by PRA.
Chris Haynes