Subject: DEPLOY: personal testimony

From: "Mark C. Langston" <[email-masked]>
Date: Thu, 2 Sep 2004 07:52:33 -0700

I am the primary author of GOSSiP, a distributed, peer-to-peer
reputation system for MTAs.  Due to the overwhelming legal analysis of
the Sender-ID licensing terms and the vagueness surrounding the actual
IPR claims, I cannot in good conscience implement Sender-ID checks in my
products.

As the Senior Unix Systems Administrator for the SETI Institute, I'm
concerned that a quick hack I may script up to check for Sender-ID would
require agreement to those terms, thereby forcing me to use an
"off-the-shelf" solution if I prefer to avoid those terms and still make
Sender-ID checks.  I'm further concerned that ANY quick hack I may
script up to do sender checks may infringe Microsoft's
yet-to-be-revealed IPR claims, and thus jeopardize my employment and my
employer.

-- 
Mark C. Langston            GOSSiP Project          Sr. Unix SysAdmin
[email-masked]   http://sufficiently-advanced.net    [email-masked]
Systems & Network Admin      Distributed               SETI Institute
http://bitshift.org       E-mail Reputation       http://www.seti.org

---

From: Matthias Leisi <[email-masked]>
Date: Sun, 05 Sep 2004 15:16:41 +0200

My interest in this working group comes both from a personal and 
business perspective. Besides my work in several non-profit projects, I 
am involved with my employer's mail infrastructure. My employer is in 
the financial services business, has around 9'000 users in Europe and 
the US (plus a number of offices around the world); for those users, we 
process roughly 5 Mio incoming mails per month.

The company has no retail business; the mail traffic is mostly with 
other companies from the financial services business. However, users are 
allowed to use mail for a limited amount of personal communication.

 From my experience, users are loosing trust in Internet mail, which 
also affects internal mail (since it can be hard for users to 
distinguish what is really an internal mail and what not). With all the 
junk and noise users receive, I would be very glad to be able to 
authenticate (the source, the sender, ... of) incoming mails. Further, 
we would like to be able to use white/blacklists on the domain level, 
which would be made somewhat easier and more effective by a "domain 
authentication" of whatever sort.

 From the sender side, both SPF and SenderId have roughly the same 
operational complexity (nearly zero, as we have only a very limited set 
of outsourced sending), so there is no reason to prefer one or the other 
(we could publish both, actually).

On the receiving side, however, SenderId introduces a certain 
complexity, whereas SPF seems easier to maintain. Due to it's 
simplicity, SPF is easier to explain /within my organization/, which 
makes it more likely to be adopted.

Given the unclear situation about IP claims surrounding SenderId, 
internal corporate legal would need to be consulted, making it less 
likely that SenderId could be deployed in a timely fashion.

It is well understood that both SenderId and SPF are more medium- than 
long-term solutions with limited scope and usefulness. From a 
cost/benefit perspective, spending too much at this point in time seems 
not justified.

For a long-term solution (eg based on some form of crypto/signing), we 
would re-evaluate the situation and be prepared to invest what will be 
required by then.

-- Matthias

-- 
Brain-Log                               http://matthias.leisi.net/