ietf-mxcomp
[Top] [All Lists]

Re: Sender-ID or SPF Classic

2004-09-01 21:13:41

                                                                      
                                                                      
                                                                      
                                          On Wed, 01 Sep 2004 20:33:42
-0400, Chuck Mead <csm(_at_)moongroup(_dot_)com> wrote:

In my own mind the choice is clear and I strongly urge
the group to support SPF-Classic and put this forward as our standard.

At this point, I'm inclined agree with you.  The Sender ID license is
definitely going to cause a lot of headaches (as I found out today
when inquiring about executing the license at my university).  Those
headaches have to be weighed against the benefit gained from Sender ID
over other alternatives.

From my point of view, the cost-benefit analysis does not favor Sender
ID.  Of course, I'm biased by the fact that pending patent claims may
adversely affect my own software by preventing me from complying with
a Sender ID standard.  I appreciate the fact that other people have
pretty different perspectives.  However, even leaving aside the highly
contentious issue of how "bad" the license terms are, I still see two
possible arguments for adopting something like SPF-classic.

First, I have not yet seen a convincing usage scenario that truly
requires Sender ID.  For every Sender ID usage scenario I can think of
(e.g., bank bulk mailing statements through a third party), something
equivalent can be achieved with an SPF-classic deployment, though
there would be slight differences.  If, in fact, SPF-classic is
sufficient for all usage scenarios (and that's a big if), then it
certainly makes sense to go with a standard that has fewer known IPR
issues.  (Any surprise patent covering SPF-classic would also very
likely cover Sender ID, so in that sense the two are equally
vulnerable to unknown IPR issues.)

Conversely, even if Sender ID were adopted, I think from discussions
here that something like SPF-classic would still be needed to thwart
viruses and joe jobs, as well as possibly to shift liability more
squarely onto "bad guys".  [I'm sure that as soon as Sender ID is
deployed, viruses will start including "Resent-Sender: virus(_at_)com" or
equivalent headers to avoid Failing Sender ID tests.]  Thus, adopting
SPF-classic now, particularly with its deployment momentum already
gaining, would be an entirely good thing.  Even if a year later we
also want to standardize Sender ID, the SPF-classic effort will
definitely not have been a waste.

I am, of course, still open to hearing about a "killer" Sender ID
application that really requires Sender ID.

David


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