Re: Sender-ID or SPF Classic

[<mazieres@xxxxxxxxx>]

                                          On Wed, 01 Sep 2004 20:33:42
-0400, Chuck Mead <csm@xxxxxxxxxxxxx> 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@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