---

C.12 Upgrading from 5.0 to 5.1

Upgrading from 5.0 to 5.1 does not require any changes in your filter scripts. Notice, however, the following important points:

• Starting from this release mailfromd supports Milter protocol version 6, which is compatible with Sendmail 8.14.0 and newer. While being backward compatible with earlier Sendmail releases, it allows you to use the new ‘prog data’ handler (see data). It also supports macro negotiation, a feature that enables Mailfromd to ask MTA to export the macros it needs for each particular handler. This means that if you are using Sendmail 8.14.0 or higher (or Postfix 2.5 or higher), you no longer need to worry about exporting macro names in sendmail.cf file.

  The same feature is also implemented on the server side, in mtasim and pmult. Consequently, using define-macros in pmult configuration file is not strictly necessary. However, keep in mind that due to the specifics of MeTA1, the number of symbols that may be exported for each stage is limited (see Translating MeTA1 macros.).

• The semantics of __preproc__ and __statedir__ built-in constant is slightly different from what it used to be in 5.0. These constants now refer to the current values of the preprocessor command line and program state directory, correspondingly. This should not affect your script, unless you redefine the default values on run time. If your script needs to access default values, use __defpreproc__ and __defstatedir__, correspondingly (see Built-in constants). The following example explains the difference between these:

  $ cat pval.mf
  prog envfrom
  do
    echo "Default value: " __defstatedir__
    echo "Current value: " __statedir__
  done
  $ mailfromd --state-directory=/var/mfd --test pval.mf
  Default value: /usr/local/var/mailfromd
  Current value: /var/mfd
  

• If your filter uses the rate function, you might consider using the new function rateok or tbf_rate instead. For a detailed discussion of these functions, see Sending Rate.
• If your script extensively uses database access functions, you might be interested in the new #pragma dbprop (see Pragma dbprop).