SpamAssissin

[RF Thomas]

Has anyone experience or distribution of spamassissin that work OepnVMS V8.2 on I64?

We need to filter spam on receipt in SMTP and understand that spanassissin has been ported and used extensively on VMS.

[Aaron Sakovich]

I've searched for this before, to no avail. SpamAssassin is PERL, so getting that to run on OpenVMS is a no-brainer. However, getting it to hook in between incoming SMTP mail and the mailbox is problematic.

Unless there's something new in the past year or so, I'd say probably not, at least not using TCP/IP Services' SMTP service. There's no facility to place a wedge or shim between the SMTP receiver and port 25.

Aaron

[RF Thomas]

When I google'd spamassissin and OpenVMS, there are lots of entries all pointing to the same distribution. There were also some ISP's who claimed to be using it on VMS, but I couldn't get very far on their links.

We are installing Perl since we don't use it internally.

The following is the install.vms file that comes with spammassissin (it makes little sense to me):
==================

Notes on building SpamAssassin on VMS
-------------------------------------

- Firstly, do not do a default build; this will build a set of C components
which currently use Autoconf to determine their dependencies, to build
"spamc".

Instead, run

perl Makefile.PL
make spamassassin

If you want "spamc" I suggest you provide a replacement header and
binaries.mk we can use, then we can special-case VMS in Makefile.PL to use
those instead of running autoconf.

- The generated Makefile.PL no longer relies on UNIX input/output
redirection; /bin/sh "for" loops; @foo "silent" directives; backslashed
continuations; or [ -f foo ] || somecommand conditionals. At least, not in
our code any more ;)

- There are still some UNIX paths inside the generated Makefile:
"rules/local.cf" for example. Suggestions on how to work around this
neatly inside the Makefile syntax while gaining VMS compatibility would be
welcome!

- "make test" will probably rely heavily on UNIX-style input and output
redirection, so will probably still fail.

- bug 1099 in the SA Bugzilla is being used to track progress.

http://bugzilla.spamassassin.org/show_bug.cgi?id=1099

[RF Thomas]

I read the whole bugzilla and things don't look too promising. It was closed two years ago. Interestingly the distribution has 2006 dates for all of the files.

Effective spam filtering might require some engineering support from HP.

[Jeremy Begg]

Hi,

I know this is not a forum for pushing 3rd party software but I think in this case it deserves a mention.

Process Software's "PreciseMail" product is a very good anti-spam filter. In an environment like the one you've described, PreciseMail is configured as an SMTP proxy server. PreciseMail comes with many anti-spam rules which are updated daily (on average) and can use SpamAssassin rules if you want it to.

Disclaimer: I use, sell and support Process Software products in Australia.

[Ian Miller.]

I also note that Quintera (as used in hp Secure Server) has a spam filter.

http://www.brilliant.com/qsoft.html

[Willem Grooters]

IIRC, the port was done by someone at HO (KArol Zielonlo, if I remember the name well), but I don't know the current status. I _know_ some people must have tried it.

[Craig A Berry · Accepted solution]

I want to comment on Aaron's comment that:

"SpamAssassin is PERL, so getting that to run on OpenVMS is a no-brainer."

Perl does have lots of great cross-platform features, but last I heard SpamAssassin uses fork(), which is not available on VMS, and also uses some features of waitpid() that are unavailable on any VMS implementation I've seen (including Perl's and the CRTL's).

I have not looked at Spamassassin in a long time, so there may be other options now (POSIX threads, for example) that could clear the way for running on VMS, but that would take some investigating.

[Aaron Sakovich]

I wasn't very clear in my comment -- I meant to imply that getting PERL to run was a no-brainer.

Sorry for any confusion.
Aaron