Regarding why the .forward file ban was not included in SSG, in http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rhel5... there is the comment "The security argument is not apparent or salient." Do you see the "no .forward files" requirement as impacting confidentiality, integrity, or availability? The description from the RHEL5 STIG in the above link indicates it potentially impacts confidentiality and availability.
I carefully considered the existing security arguments and still ended up labeling very much of the 1990s best practices items with "security argument is not apparent or salient." Credible security arguments can certainly be presented if they exist. Here, I felt an out-of-date or otherwise unconvincing argument was presented, for the reasons below. (By the way, adding notes to input/auxiliary/transition_notes.xml is an open invitation to all.)
It mentioned "unauthorized forwarding of email" and while I have little doubt that someone in a position of authority would like for all use of the email "forward" button to require some kind of authorization (perhaps some kind of standard form, for each message to be forwarded, also per recipient), this doesn't quite seem realistic. I could not conjure any difference in risk between piecemeal forwarding and forwarding as a rule.
Regarding mail loops, Postfix (and other modern MTAs) include a significant number of countermeasures to address this risk.
Are those indications sufficient for addition to the SSG, perhaps with a low severity?
For the security discussion (non-compliance) portion, it's certainly worth including as a discussion point (and making available as a Rule for parties who may have specific use cases where this might really matter). For a baseline with a wide audience such as the STIG, I had argued against inclusion. But if you feel that there's value in enforcing this as a compliance check (which is to say, that the security benefits outweigh the costs as part of maintaining the baseline as well as of enforcement itself), please say so and throw a patch up to the list.
There is also an interesting security argument for permitting forwarding. When remote email access to a corporate account is (often inexplicably or lazily) denied, forwarding allows users to receive email that has at least been santized via corporate email services. The predictable alternative user behavior is to use entirely non-corporate services for remote email connectivity. It is a very interesting risk comparison.
Would "forward_path = /dev/null" in /etc/postfix/main.cf be an adequate solution?
man(8) local tells me that should do it.
In a similar vein, should there be a "sendmail must not be installed" rule? ;-)
Yes! I thought that this would have carried over from the RHEL 5 USGCB rules, but I suppose it got lost in the shuffle. I just added it, and to the Profile too.
I've read significant amounts of both the Sendmail and Postfix code, and I _strongly_ support this.