Gary Funck <[EMAIL PROTECTED]> [2002-09-21 13:59:38 -0700]: > Our mail server computer is offline at the moment, so we substituted > a spare, which generally has the same OS and software, but differs > in a few regards. It > [...] > The -P flag used to be in the recipe, but I removed it after > upgrading to v. 2.41 because I saw warning messages in procmail log > file, where the new version of SA noted that the -P flag is no > longer necessary.
That was a good thing, that you saw the message and updated. Years into the future it is desired to forget that the -P option existed. It was a mistaken step in the development path of SA. The developers are moving foreward. Note that I am not an SA developer and I am speaking my own mind here. But by what method can one transition from a previous version to a newer version where incompatibilities exist? It is very difficult but the path chosen by the SA developers is as good as anyone has ever been able to do. They created a transition version where the -P option is only a warning. As users move through that version and on to future versions they can transition their configurations to follow. > Suggestion: remove the -P warning. The presence of -P doesn't hurt anything, > and the lack of backward compatibility can cause some surprising behavior. You are not experiencing a _backward_ compatibility problem but a _forward_ compatibility problem. You are moving from a newer version to an older version and that is creating your problem. You have two hosts one of which you are using as an alternate for the other. Therefore is is possible for you to go backwards from a newer version to an older version when you fail over from one host to the other. You have a configuration which is probably seen by a relatively small number of people. Moving from a newer version to an older version is not an expected situation. That problem is called forward compatibility, the opposite of backward compatibility, and in general cannot be handled by the software program. The older version has already been released by the time you determine that you need to handle a problem in the forward case. Only backward compatibility can be handled gracefully. The future knows about the past but the past does not know about the future. This is not specific to SA but is true of all software. Therefore shouldn't your fail over host always be in close software synchronization to your primary? If not then isn't there a greater responsibility upon you as the maintainer of that failover host configuration to know what is compatible between the two hosts and what is not compatible? To know what configuration will be shared by those hosts and what configuration will be unique to those hosts? Certainly no one else is in a position to know the particulars of your specific situation. I personally would have guessed that the procmail recipe which used the -P or not would have been specific to the host. You might just have easily have had different procmail versions on the machines and different procmail flags might have been used. Obviously I would have guessed wrong since you configured your systems differently. Again, only you as the maintainer of those systems know that information. Therefore there is, of course, a counter suggestion as well. You should upgrade your secondary host to the newer version. And you should keep your secondary in close sync with your primary for all software and not just SA. Anything that is out of sync between machines that can substitute for each other will need to be closely monitored so that when you do substitute one for the other that you can make adjustments as needed. Bob
msg08003/pgp00000.pgp
Description: PGP signature
