Subject: RE: Motion to abandon Sender ID

From: [email-masked]
Date: Thu, 2 Sep 2004 11:58:56 -0400

>> 
>
>I am sure that we can come up with multiple conspiracy 
>theories for this. For now, lets stay above the fray and 
>assume that perhaps Microsoft was acting in good faith. 
>Descending into conspiracy theories will not make this any 
>better, and quite the opposite, will make the entire 
>discussion appear unprofessional.
>
>Microsoft knows what the issues are, they are receiving 
>comments from multiple people and sources. The decision on  
>the license is upto them. 
>The decision on the standard on the other hand is upto the us.
>
>Yakov
>
>

IMHO...(short version)

I will recommending that we move forward with the implementation of
SenderID within Bell Canada (over 35,000 domains) as I believe the
licensing component has zero to do with the technology and cost of
implemention. The support that Microsoft will generate over night for
this solution will drive global adoptation - something this solution is
going to need to be successful.

Jonathan

---

From: Kevin Peuhkurinen <[email-masked]>
Date: Thu, 02 Sep 2004 13:05:46 -0400

Hi Jonathan.   Thanks for your input.    You say that you are going to 
recommend going forward with Sender-ID, even though it has gone through 
no real testing and has not been adopted as a standard yet.    Is your 
recommendation based solely on the belief that Microsoft's backing will 
ensure it's success despite the resistance from the open source camp or 
do you feel that it is a superior technology to, say, SPF?

Also, I have noticed that the MTAs that Bell uses includes the GPL'ed 
Exim and the ASL licensed InterMail.    Do you expect to have to replace 
these with Sendmail?

Thanks,
Kevin

---

From: Ryan Ordway <[email-masked]>
Date: Thu, 02 Sep 2004 10:23:32 -0700

> going to need to be successful.

	Gee, amazing how the Internet ever managed to come
into existence without Microsoft!

	A big company's backing does not a successful protocol
make. More likely, if certain key ISPs were to start checking
MARID records and making actual decisions based upon their
content, this would drive support for the protocol. From
-rationale-00:

7.2. Marketing Analysis: Chasm Theory

 The designed product, and the augmentations that surround it, must 
 survive each phase of Geoffrey Moore's Chasm model.

 The core specification should be attractive enough to the visionaries 
 to seed the fax effect by publishing records and writing libraries.

 After an initial round of discovery and experimentation by the early 
 adopters, the mainstream must be encouraged to start publishing 
 records.  This is the first chasm, on the publishing side.  They need 
 the assurance that publishing records will, first, do no harm.

 The beachhead for crossing the publishing-side chasm turned out to be 
 industry leaders.  When enough well known domains published records, 
 they seeded the second round of the fax effect.  The second round turns 
 potential receiver-side implementors into actual implementors:
 the early adopters here are the makers of antispam email appliances and 
 edge MTAs such as CipherTrust, IronPort, Postini, and Brightmail.
 They are ideally positioned to implement Sender ID checking on inbound 
 mail and have a business reason to do so.

 The second chasm, on the receiving side, requires major ISPs to start 
 implementing inbound checking.  Their initial motivation is to reduce 
 the costs of whitelisting.  Major ISPs negotiate email peering 
 relationships with major senders and maintain, often by hand, 
 whitelists of IP addresses.  Conversion to Sender ID-based whitelisting 
 is an obvious step.  Note that while Sender ID is often viewed as an 
 anti-forgery mechanism, using it as a whitelisting mechanism is simply 
 the other side of the coin.

 After these chasms are crossed, there remains the challenge of getting 
 publishers to transition through increasing levels of severity: from 
 "?" to "~" to "-".  This effort requires cooperation from receivers.

	I see no mention of Microsoft in there anywhere!

	My apologies if I dripped any sarcasm on you.

	Ryan

-- 
HELO, my name is root... you have SIGKILLed my father... prepare to vi!

---

From: Jonathan Gardner <[email-masked]>
Date: Thu, 2 Sep 2004 12:39:53 -0700

> going to need to be successful.

Jonathan, I believe that Bell can successfully implement Sender ID, and sign 
whatever agreements need to be signed with Microsoft ot license their 
patent (pending, yada yada yada).

However, the problem isn't with individual email service providers who don't 
use open source software to run their email services. It is with those 
people who use major Linux and BSD distributions to run their email 
services.

Take the example of a small company that hosts their own email services in 
house. Their email server is installed with a standard Linux or BSD 
distribution. For the sake of argument, let's take my situation at my home 
business.

I run Red Hat Fedora Core 1 on my server. While I am able to download, 
compile, and install additional software, I prefer not to on my email 
server. The reason is that I need the updates that flow through the 
channels. I need the testing and the configuration that others have put 
into the distribution. It's also much easier to use the software management 
system (in this case, RPM and Yum) that comes with the distribution. 
Therefore, my policy is not to install anything that is not part of the 
standard distribution. In fact, I favor sendmail over the other MTA servers 
because it is the default and has a larger base, and it thus gets more 
testing and more configuration documentation is available on the internet.

I probably won't be able to maintain a Sender ID compliant MTA. At best, I 
would have to download additional RPMs from a licensed distributor. That's 
not a big problem. The big problem comes with whether or not there is a 
large enough number of people doing the same thing. I need to rely on their 
testing and their configuration experience in setting up my experience. 
Since this software will have to be downloaded seperately, it will never 
get a large installed base among Fedora users. But also consider the extra 
time it takes to locate the package and find the right one, or the one with 
the latest updates. That can be a problem, and it will at the very least 
take some time, and at worst, take a lot of time. That's time I don't have 
to spend right now.

I admit that I am using the SPF milter software available in RPM form. 
However, I haven't been able to upgrade recently because compatibility with 
my fedora core installation has become an issue. So I haven't upgraded for 
some time. Unlike Sender ID, SPF stands a very good chance of becoming part 
of the distribution itself, and perhaps part of the default MTA 
installation. Because it isn't right now, that is harming the adoption of 
SPF being incorporated into the MTAs on Fedora.

If the Sender ID technology could be incorporated into the Fedora 
distribution, it will get a much larger user, and thus, testing base. More 
documentation will be available. Also, if it is part of the default MTA 
installation, more people would use it, and it would become the de facto 
standard for Fedora users. The same is true for any other distribution.

- -- 
Jonathan M. Gardner