spf-discuss
[Top] [All Lists]

Re: Moving Forward ...

2004-10-14 04:06:14

On Wed, 13 Oct 2004, Meng Weng Wong wrote:

On Wed, Oct 13, 2004 at 05:13:30PM -0400, John Glube wrote:
| 
| From the last go around, the clear consensus was that the
| spfv1 protocol should not consider pra checking.
| 

OK, let me try to get some clarification on this.

1) what exactly is everyone's objection to allowing v=spf1
   records to be interpreted in PRA scope?

The problem is possible misrepresentation of the intent of the publisher.
When somebody published v=spf1 records they have intent that record 
being used according to just published draft for purposes of authorizating 
use of RFC2821 Mail From. They may not want to have these records used for 
anything else as they have no ideas how those "other" authentication methods
would work and there is possibility that header-based authentication system
proposed by microsoft is dangerous and would result is large number of 
false positives.

Let's set aside for now the issue of scope disambiguation whether
using a macro or a /scope tag, and assume that PRA record content
would be the same as for mailfrom record content.

We should not make such an assuption. We should not assume that people who 
published v=spf1 record per requiest of Microsoft have any ideas that record
may also be used for Mail-From and we what about all those already published
v=spf1 records? They certainly have not authorized them being used for 
SenderID. 

If somebody wants to publish record to be used for multiple verification 
methods (different scopes) they should be required to explicetely do it
and required to have read all documentation on what each one of those
scopes represents.

2) if MS changed the patent license to be compatible with
   free software, would those objections go away?

It would allow those whing to do it to include PRA checking in opensource
software packages. However technical problems with PRA would still remain
as it is possible that PRA in itself is a flawed approach and that their 
specification actually violates current IETF RFC standards. 

3) would people rather see Microsoft promote an spf2.0/pra
   syntax, while the opensource world promotes a v=spf1
   syntax?
Yes, but I don't think we're ready with "spf2.0/pra" syntax and I think
we should not move marid-protocol forward at this time.

I would rather that we first work more on the non-scope specific specification 
for next version of SPF specification that includes syntax for supporting 
multiple scopes. I do not believe that latest marid protocol draft was
best way of doing it and I think more work is needed on that specification.

After we're done with syntax of that document, I believe SPF community 
would need to work on separate documents describing using each specific 
scope as well as general BCP-like document describing how non-encumbered 
scopes can be used together to create "Unified" spf checking system.

In separate post I have already written why working with Microsoft is
not in the best interest of SPF community politically, however that
does not mean we should actively oppose them. I believe that SPF needs
to work on UnifiedSPF in a way that we do not mention PRA or Microsoft
at all but still allow them to write independent specification that
can use new v2 protocol specification and allow then to define new
scope for PRA in their draft. All these documents will need to be 
submitted to IETF first as drafts and then to IETF Directorate for
publication as EXPERIMENTAL RFCs.

If any draft is denied EXPERIMENTAL status (any UnifiedSPF scope or 
Microsoft PRA scope), then SPF community would need to decide on its
own if it wants to continue using the document anyway. If there is
no support for using the document and it did not pass IETF review then 
use of such specification should then be actively discoraged by SPF.

---
William Leibzon, Elan Networks:
 mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/


<Prev in Thread] Current Thread [Next in Thread>