Merge pull request #1903 from evgenyz/rename_blacklist_for_modprobe_in_test_ds

tests: Rename blacklist to denylist

Author: matejak

tests/API/XCCDF/parser/xccdf11.xml

@@ -3422,7 +3422,7 @@
         </Group>
         <Group id="scap-rhel5-group-3.11.3.3" hidden="false">
           <title xml:lang="en">Control Mail Relaying </title>
-          <description xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en">The sending of Unsolicited Bulk E-mail, referred to variously as UBE, UCE, or spam, is a major problem on the Internet today. The security implications of spam are that it operates as a Denial of Service attack on legitimate e-mail use. Strategies for fighting spam receipt at your site are complex and quickly evolving, and thus far beyond the scope of this guide. The problem of relaying unauthorized e-mail, however, can and should be addressed by any network-connected site. Most MTAs perform two functions: to accept mail from remote sites on behalf of local users, and to allow local users to send mail to remote sites. The former function is relatively easy — mail whose recipient address is local can be assumed to be destined for a local user. The latter function is more complex. Since it is typically considered neither secure nor desirable for users to log in to the MTA host itself to send mail, the MTA must be able to remotely accept mail addressed to anyone from the user’s workstation. If the MTA is running very old software or is configured poorly, it can be possible for attackers to take advantage of this feature, using your MTA to relay their spam from one remote site to another. This is undesirable for many reasons, not least that your site will quickly be blacklisted as a spam source, leaving you unable to send legitimate e-mail to your correspondents. The simplest solution described in this guide is to configure the MTA to relay mail only from the local site’s address range, and some variant on this is the default for most modern MTAs. That solution may be insufficient for sites whose users need to send mail from remote machines, for instance while travelling, as well as for sites where mail submission must be accepted from network ranges which are not considered secure, either because authorized machines are unmanaged or because it is possible to connect unauthorized machines to the network. If remote or mobile hosts are authorized to relay, or if local clients exist in insecure netblocks, the SMTP AUTH protocol should be used to require mail senders to authenticate before submitting messages. For better protection and to allow support for a wide range of authentication mechanisms without sending passwords over a network in clear text, SMTP AUTH transactions should be encrypted using SSL. Another approach is to require mail to be submitted on port 587, the designated Message Submission Port. Use of a separate port allows the mail relay function to be entirely separated from the mail delivery function. This may become a best practice in the future, but description of how to configure the Message Submission Port is currently beyond the scope of this guide. See RFC 2476 for information about this configuration. </description>
+          <description xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en">The sending of Unsolicited Bulk E-mail, referred to variously as UBE, UCE, or spam, is a major problem on the Internet today. The security implications of spam are that it operates as a Denial of Service attack on legitimate e-mail use. Strategies for fighting spam receipt at your site are complex and quickly evolving, and thus far beyond the scope of this guide. The problem of relaying unauthorized e-mail, however, can and should be addressed by any network-connected site. Most MTAs perform two functions: to accept mail from remote sites on behalf of local users, and to allow local users to send mail to remote sites. The former function is relatively easy — mail whose recipient address is local can be assumed to be destined for a local user. The latter function is more complex. Since it is typically considered neither secure nor desirable for users to log in to the MTA host itself to send mail, the MTA must be able to remotely accept mail addressed to anyone from the user’s workstation. If the MTA is running very old software or is configured poorly, it can be possible for attackers to take advantage of this feature, using your MTA to relay their spam from one remote site to another. This is undesirable for many reasons, not least that your site will quickly be denylisted as a spam source, leaving you unable to send legitimate e-mail to your correspondents. The simplest solution described in this guide is to configure the MTA to relay mail only from the local site’s address range, and some variant on this is the default for most modern MTAs. That solution may be insufficient for sites whose users need to send mail from remote machines, for instance while travelling, as well as for sites where mail submission must be accepted from network ranges which are not considered secure, either because authorized machines are unmanaged or because it is possible to connect unauthorized machines to the network. If remote or mobile hosts are authorized to relay, or if local clients exist in insecure netblocks, the SMTP AUTH protocol should be used to require mail senders to authenticate before submitting messages. For better protection and to allow support for a wide range of authentication mechanisms without sending passwords over a network in clear text, SMTP AUTH transactions should be encrypted using SSL. Another approach is to require mail to be submitted on port 587, the designated Message Submission Port. Use of a separate port allows the mail relay function to be entirely separated from the mail delivery function. This may become a best practice in the future, but description of how to configure the Message Submission Port is currently beyond the scope of this guide. See RFC 2476 for information about this configuration. </description>
         </Group>
       </Group>
       <Group id="scap-rhel5-group-3.11.4" hidden="false">

tests/API/XCCDF/parser/xccdf12.xml

@@ -3442,7 +3442,7 @@
         </Group>
         <Group id="xccdf_org.open-scap_group_scap-rhel5-group-3.11.3.3" hidden="false">
           <title xml:lang="en">Control Mail Relaying </title>
-          <description xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en">The sending of Unsolicited Bulk E-mail, referred to variously as UBE, UCE, or spam, is a major problem on the Internet today. The security implications of spam are that it operates as a Denial of Service attack on legitimate e-mail use. Strategies for fighting spam receipt at your site are complex and quickly evolving, and thus far beyond the scope of this guide. The problem of relaying unauthorized e-mail, however, can and should be addressed by any network-connected site. Most MTAs perform two functions: to accept mail from remote sites on behalf of local users, and to allow local users to send mail to remote sites. The former function is relatively easy — mail whose recipient address is local can be assumed to be destined for a local user. The latter function is more complex. Since it is typically considered neither secure nor desirable for users to log in to the MTA host itself to send mail, the MTA must be able to remotely accept mail addressed to anyone from the user’s workstation. If the MTA is running very old software or is configured poorly, it can be possible for attackers to take advantage of this feature, using your MTA to relay their spam from one remote site to another. This is undesirable for many reasons, not least that your site will quickly be blacklisted as a spam source, leaving you unable to send legitimate e-mail to your correspondents. The simplest solution described in this guide is to configure the MTA to relay mail only from the local site’s address range, and some variant on this is the default for most modern MTAs. That solution may be insufficient for sites whose users need to send mail from remote machines, for instance while travelling, as well as for sites where mail submission must be accepted from network ranges which are not considered secure, either because authorized machines are unmanaged or because it is possible to connect unauthorized machines to the network. If remote or mobile hosts are authorized to relay, or if local clients exist in insecure netblocks, the SMTP AUTH protocol should be used to require mail senders to authenticate before submitting messages. For better protection and to allow support for a wide range of authentication mechanisms without sending passwords over a network in clear text, SMTP AUTH transactions should be encrypted using SSL. Another approach is to require mail to be submitted on port 587, the designated Message Submission Port. Use of a separate port allows the mail relay function to be entirely separated from the mail delivery function. This may become a best practice in the future, but description of how to configure the Message Submission Port is currently beyond the scope of this guide. See RFC 2476 for information about this configuration. </description>
+          <description xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en">The sending of Unsolicited Bulk E-mail, referred to variously as UBE, UCE, or spam, is a major problem on the Internet today. The security implications of spam are that it operates as a Denial of Service attack on legitimate e-mail use. Strategies for fighting spam receipt at your site are complex and quickly evolving, and thus far beyond the scope of this guide. The problem of relaying unauthorized e-mail, however, can and should be addressed by any network-connected site. Most MTAs perform two functions: to accept mail from remote sites on behalf of local users, and to allow local users to send mail to remote sites. The former function is relatively easy — mail whose recipient address is local can be assumed to be destined for a local user. The latter function is more complex. Since it is typically considered neither secure nor desirable for users to log in to the MTA host itself to send mail, the MTA must be able to remotely accept mail addressed to anyone from the user’s workstation. If the MTA is running very old software or is configured poorly, it can be possible for attackers to take advantage of this feature, using your MTA to relay their spam from one remote site to another. This is undesirable for many reasons, not least that your site will quickly be denylisted as a spam source, leaving you unable to send legitimate e-mail to your correspondents. The simplest solution described in this guide is to configure the MTA to relay mail only from the local site’s address range, and some variant on this is the default for most modern MTAs. That solution may be insufficient for sites whose users need to send mail from remote machines, for instance while travelling, as well as for sites where mail submission must be accepted from network ranges which are not considered secure, either because authorized machines are unmanaged or because it is possible to connect unauthorized machines to the network. If remote or mobile hosts are authorized to relay, or if local clients exist in insecure netblocks, the SMTP AUTH protocol should be used to require mail senders to authenticate before submitting messages. For better protection and to allow support for a wide range of authentication mechanisms without sending passwords over a network in clear text, SMTP AUTH transactions should be encrypted using SSL. Another approach is to require mail to be submitted on port 587, the designated Message Submission Port. Use of a separate port allows the mail relay function to be entirely separated from the mail delivery function. This may become a best practice in the future, but description of how to configure the Message Submission Port is currently beyond the scope of this guide. See RFC 2476 for information about this configuration. </description>
         </Group>
       </Group>
       <Group id="xccdf_org.open-scap_group_scap-rhel5-group-3.11.4" hidden="false">