Subject: Sender-ID or SPF Classic

From: Chuck Mead <[email-masked]>
Date: Wed, 01 Sep 2004 20:33:42 -0400

All: at present it appears to me that we are being forced by the
Microsoft license to leave Sender-ID behind. If we do not we will cause
implementation problems for a huge community of people running OSS MTA's
(the majority of internet MTA's in fact). This means that this working
group has a clear decision to make. Do we continue to press on with
Sender-ID and cause this problem or do we choose SPF-Classic and move
forward with it. 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.

- --
[email-masked], head geek
http://moongroup.com

---

From: <[email-masked]>
Date: Thu, 2 Sep 2004 00:13:42 -0400

On Wed, 01 Sep 2004 20:33:42
-0400, Chuck Mead <[email-masked]> wrote:
> 
> In my own mind the choice is clear and I strongly urge

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