Mail Server Upgrades (Procmail Users)

[kgc]

Thursday morning we're going to replace the mail server cluster that handles delivery to customer mail spools. For 99.999% of users this change will go completely unnoticed and will result in slightly faster mail delivery. However, if you are one of the few hundred users that are currently using procmail to filter your mail on the server there is a small chance that the upgrade may cause you trouble.

If your procmail is limited to pattern matching and other built in functionality it is very likely that it will continue to work as expected. However, if you shell out to external programs it is possible that those programs may or may not work or even be present on the new servers. There was a substantial OS upgrade behind the scenes and given the flexibility of procmail it is impossible for us to test compatibility.

It is not practical for us to setup a system that would allow users to test their procmail rules in advance of the move. If you are concerned that your rules may run run afoul of the upgrade the best thing to do is temporarily disable them until we've completed the upgrade and you can test them in a controlled fashion.

The only other issue of note is that the upgrade will result in all vacation/auto-response databases being reset, the only affect being that remote senders may receive another auto-response before they normally would have if the databases were not reset.

[rknop]

If we shell out to a script in our home directory, will that exist on the new server? (In particular, although the filter probably hasn't been hit in years, I had one that shelled out to a simple perl script in my .procmail directory.)

[kgc]

Yes, that should still work providing that the perl script runs okay on the new server. (It looks like it should work fine after I added a symlink to /usr/bin/perl from /usr/local/bin/perl.)

[sidney]

I guess if shelling out to scripts in the home directory may work, then $HOME will still be set and can be used, correct?

Will .procmailrc-first and other details of the scripts that call spamassassin still be the same, such as my conditional use of

INCLUDERC=/opt/protect/etc/spamassassin-sql.rc

in ~/.procmailrc-first ?

Will the following continue to work to put mail in the graymail folder?

GRAYBOX=`/opt/protect/bin/get_graymail_dir`
:0
$GRAYBOX

Will /usr/bin/tee still exist?

I think that is all the nonstandard stuff I do other than inside test code that aren't triggered by ordinary email.

[kgc]

Sidney, the new hosts are RHEL 6 so it is possible that some paths have changed but it is easy to figure this out by checking out another host. Otherwise expect all variables and other sonic specific things to continue to behave as before.