-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 02 September 2004 08:58 am,
jonathan(_dot_)curtis(_at_)bell(_dot_)ca wrote:
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, 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFBN3cJBFeYcclU5Q0RAs/0AJ4r6ExOL4TZ3gFMVI6BjmTc36gPTwCguVcW
XIX6fNVnHhACdd/9Ealb0Lg=
=lJWh
-----END PGP SIGNATURE-----