Request for Perl module Encode::compat

[casner]

When running a Perl script in a shell on bolt.sonic.net, the Perl module Encode::compat is available in the default include path, but when running the same script from procmail on the mail servers, that module is not available. Can it be installed there?

(Actually, it would be much nicer to have the module Encode, but that requires a newer Perl, which probably requires a newer Linux kernel. Any plans for an update any time soon?)

[kgc]

The perl version on the mail servers is significantly newer than what is on the shell server. Encode is there and probably most other commonly use mail modules. I'd suggest setting up a test rule to run it and watch the logs.

FWIW, They are REHL 6.x servers, running 5.10.1

[casner]

Aha, I raised this question because I found failures on the decode() call in the procmail log, so then I began testing in the shell environment and found that Encode was missing but Encode::compat was present, but that failed when called from procmail. The original failure may have been for a different reason.

It would be really nice to be able to test scripts in the shell environment. Any chance of that environment being upgraded any time soon?

[kgc]

I can't promise anything but we are likely to address it relatively soon. However, there is a chance that some of the other changes that it brings are going to be unpopular. First of all, there's a good chance that we're going to disable direct access to the mail spools. Continuing to run shell-reader compatible mail spools eliminates some appealing options for scaling out our mail storage while also improving performance for users. There's also the possibility that procmail will be deprecated for sieve.

We're unlikely to eliminate procmail entirely, but continuing to use it, for example, might mean your mail gets shunted away from the main cluster.