ietf-mxcomp
[Top] [All Lists]

Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd)

2004-10-29 09:43:08
On Thu, 2004-10-28 at 16:41 -0500, wayne wrote:

I disagree. SenderID/SPF is currently in deployment and is working just 
fine in production. Maturity was not the problem. 

SenderID != SPF.  Please don't associate the two.  This entire merging
of technologies was such a horribly stupid idea.  Can someone remind me
why we took a perfectly progressive, active and supported technology
that was OPEN and FREE and decided to take it out back and beat the
living tar out of it?  Oh thats right "we" didn't make that decision.
Funny how that works.

SPF-classic is currently widely deployed.  SenderID, and the new
SPF-classic, however, are not deployed.  What little information about
the performance of SenderID indicates that it is probably not as
reliable as old SPF-classic.

Maturity certainly was a problem.  

I would consider DK before SenderID, its most certainly more mature and
it also hasn't spent the last ~6 months beating around the proverbial
bush debating stupid software patents.

Cheers,

James

James Couzens,
Programmer
                        ^                            ( ( (      
      ((__))         __\|/__        __|+|__        '. ___ .'    
       (00)           (o o)          (0~0)        '  (> <) '    
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

Attachment: signature.asc
Description: This is a digitally signed message part

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