_FFR...

_FFR...

---

Try using future features

tune with confENVDEF

Inside the sendmail code are pieces of new code, which can add new features, options, macros, and the like, that might appear in V8.13 and above versions of sendmail . You can include any of these new pieces of code by defining one of the following _FFR (For Future Release) m4 Build macros when building sendmail :

 APPENDDEF(`conf_sendmail_ENVDEF', `-D_FFR_  what')    affects sendmail only  APPENDDEF(`conf_makemap_ENVDEF', `-D_FFR_  what')    affects makemap only  APPENDDEF(`confENVDEF', `-D_FFR_  what')    affects all programs  

Here, what describes the appropriate future item that you want to include (as found in the source). Consider the following example:

 APPENDDEF(`confENVDEF', `-D_FFR_QUARANTINE=1') 

Here, the _FFR_QUARANTINE m4 Build macro is defined so that the sendmail and mailstats programs can support queue quarantining of messages.

If you are running a precompiled binary of sendmail , you can determine whether any of the _FFR macros were defined when sendmail was compiled by using the -d0.13 debugging switch (-d0.13):

 %  /usr/sbin/sendmail -d0.13 -bt  Version 8.12.3  Compiled with: DNSMAP LOG MAP_REGEX MILTER MIME7TO8 MIME8TO7 NAMED_BIND  etc  ...   FFR Defines: _FFR_QUARANTINE   note   etc  ... 

Note that by running any of the sendmail suite of programs with an FFR defined, you are, in effect, acting as a guinea pig for the sendmail development team. You will be utilizing new features in production and, by doing so, can uncover bugs that will help solidify the code before it is released to the public. If you elect to do this, and if mail delivery breaks, first install a clean (non-_FFR) version of sendmail to determine if the _FFR was responsible. If it turns out to be responsible, describe the problem in detail, include your mc configuration file (not your cf file) and any log messages of relevance, and send that information to [e-mail].