Title: RE: [SAtalk] Re: An Open Letter to the SA-talk forum

Ken,

I think that the reason you can't imagine it taking longer than five minutes to install is that you've done it a few times. I'm a reviewer, not a full-time Linux administrator, and don't have enough time to keep up with all the various versions. I review products on all the various versions of Windows, Solaris, Mac, Linux, NetWare and so forth.

I had to locate the RPM on the RedHat disks, install the package, then go back and then install the dependencies that hadn't been installed in the first place. Then I had to go through the documentation and see what files needed to be changed and how, make those changes, and then test the result. The whole process took me a little over an hour.

Regarding Brightmail, I didn't try installing it on Linux, but I did look at the documentation. There is a script that checks dependencies, and an installation wizard that takes you through the configuration information, pointing at the mail server (which doesn't have to be either sendmail or postfix - it can be Exchange or something else on another system), and filling in the other configuration information. Once the wizard runs, Brightmail is ready to go - no files to edit. 

The documentation was hard for me to find because I'm not a regular enough user of Red Hat that I instantly found the usr/share/doc tree, and the SpamAssassin.org site link to the 2.44 docs is broken. In addition, once I found the files, I found them rather difficult to wade through, since they assume a fairly high level of expertise.

Using procmail or one of the other packages to filter is what I meant be filtering must be set up. Unfortunately, with five anti-spam packages to cover in 2600 words, my ability to go into detail is pretty limited.

I'd say that the commercial lists offer guarantees, in the sense that they're maintained by companies with paying customers, while the noncommercial lists are maintained by volunteers who might (in one recent case) put the entire Internet into his black hole list and then disappear.

I can imagine an administrator telling the CIO that he won't give an email account to anyone who can't use a text editor to edit a whitelist file. I can also imagine that admin leaving the CIO's office at a high rate of speed with a boot print on his butt.


Thanks,

Logan G. Harbaugh
530 222-1164
693 Reddington Drive
Redding, CA 96003
www.lharba.com

 -----Original Message-----
From:   Kenneth Porter [mailto:[EMAIL PROTECTED]]
Sent:   Wednesday, November 26, 2003 5:49 PM
To:     Logan G. Harbaugh; [EMAIL PROTECTED]
Subject:        RE: [SAtalk] Re: An Open Letter to the SA-talk forum

BTW, Logan, can you say (on the list, use "reply all") why it took an hour
to install SA? I can imagine it taking me that long only because I'm very
careful and look at the installation scripts to make sure nothing will
break my existing setup. That option of course doesn't exist with closed
source, and the best I can do instead is to study the release notes. I also
compile from source to tune SA to my system but could in principle use a
canned RPM, eliminating the build time.

The only real "setup" I had to do was to add the line to my procmailrc to
invoke SA. That's about the same level of complexity as changing MX records
for the two services you reviewed.

I'd be curious to see how Brightmail installs on Unix systems. Installing
on Exchange is likely to be easy because Exchange is such a closed system
and the options and unknowns for an installer are so small. On Unix it has
to handle both sendmail and postfix (and whatever delivery system is used)
and the list of supported OS's includes RH7.2, which lacks milter, so it
can't use that for the connection.

For quick reference, here's the relevant part of the InfoWorld article:

> I installed SpamAssassin Version 2.44 along with Red Hat Linux 9.
> Installing Red Hat 9 is easy, and the SpamAssassin package is included
> with the mail server installation. But just because the software is
> installed does not mean it will work -- filtering criteria must be added
> manually, and until that's done nothing is filtered out. Getting the
> various configuration files edited properly so that the whole package
> worked was not simple. Documentation was difficult to find, and not
> always easy to follow.
>
> There are blacklists available that you can subscribe to, and some are
> updated regularly, but these are noncommercial lists with no guarantees.
> The whitelist is not difficult to add to, but there is no mechanism for
> end-users to add to the whitelist or to automatically notify the
> administrator to add senders. Filtering rules are relatively basic, and
> although there is a Bayesian filter available, it is not part of the
> distribution -- and I wasn't able to get it working for this review.

I found documentation in two places. The first, familiar to anyone using
Red Hat, is the /usr/share/doc tree, which contains a subdirectory for each
installed package. The second is the SA website. What made these "hard to
find"?

You mention that filtering must be set up, but note that SA doesn't filter,
by design. It simply tags and leaves it up to other components (eg.
procmail, MIMEDefang) to filter. (Admittedly the text on the SA home page
is a little confusing on this issue.)

If you say that noncommercial blacklists offer no guarantees, are you
implying that there are commercial lists with guarantees? What's the
guarantee?

As I mentioned in another message, end users *can* edit the whitelist. It
requires editing a text file (which admittedly is beyond the capabilities
of the average PHB), but it can be done. In fact, a test for the ability to
do this might make a good prerequisite for allowing someone in one's
company an email account!

The lack of the Bayesian filter is of course due to the ancient version you
reviewed, and I think you've taken enough grief for that. ;)

Ken

Reply via email to