kriterion 0.0.1

data/standards/stig_microsoft_exchange_2010_mailbox_server_role.json

@@ -0,0 +1,107 @@
+{
+  "name": "stig_microsoft_exchange_2010_mailbox_server_role",
+  "date": "2012-05-31",
+  "description": "The Microsoft Exchange Server 2010 STIGs cover four of the five roles available with Microsoft Exchange Server 2010, plus core Exchange Server 2010 global requirements. The Email Services Policy STIG must also be reviewed for each site hosting email services. The core Exchange Server guidance must be reviewed on each server role prior to the role-specific guidance. Also, for the Client Access server, the IIS guidance must be reviewed prior to the OWA checks.",
+  "title": "Microsoft Exchange 2010 Mailbox Server Role",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "EXCH-MB-400",
+      "title": "Mail quota settings must not restrict receiving mail.",
+      "description": "Mail quota settings control the maximum sizes of a user's mailbox and the system's response if these limits are exceeded.   Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable.   There are three controls, which supply graduated levels of opportunity to respond before risking data loss.  \n\nThis control impedes users in their ability to work, and is not recommended, as mail interruption is not acceptable.",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-MB-401",
+      "title": "Mail Store storage quota must be limited.",
+      "description": "Mail quota settings control the maximum sizes of a user's mailbox and the system's response if these limits are exceeded.   Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable.   There are multiple controls, which supply graduated levels of opportunity to respond before risking data loss.  \n\nThis control prohibits the user from sending an email when the mailbox limit reaches the prohibit send quota value.\n\nNote: Best practice for this setting is to prohibit the user from sending email when the mailbox reaches 90 percent of capacity.",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-MB-402",
+      "title": "Mail Store storage quota must issue a warning.",
+      "description": "Mail quota settings control the maximum sizes of a user's mailbox and the system's response if these limits are exceeded.   Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable.   There are multiple controls, which supply graduated levels of opportunity to respond before risking data loss.  \n\nThis control sends the user a warning message that the mailbox is reaching its limit. The user at this point can still send and receive email.\n  \nNote: Best practice is to send this warning when the mailbox reaches 75 percent of capacity.",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-MB-403",
+      "title": "Public Store storage quota must be limited.",
+      "description": "This setting controls the maximum sizes of a Public Folder and the system's response if these limits are exceeded. There are two available controls and the system response when the quota has been exceeded. \n\nThe first control sends an email warning to Folder Owners roles alerting them that the folder has exceeded its quota.  The second level prevents posting any additional items to the folder.  \n\nAs a practical matter, level 1 serves the purpose of prompting owners to manage their folders.  Level 2 impedes users in their ability to work, and is not required where folder use interruption is not acceptable.   Public Folder Storage Quota Limitations are not a substitute for overall disk space monitoring.",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-MB-404",
+      "title": "The Mailbox Stores must mount at startup.",
+      "description": "Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Mailbox data manipulation.  Occasionally, there may be a need to start the server with 'unmounted' data stores,  if manual maintenance is being performed on them.  Failure to uncheck the 'do not mount on startup' condition will result in unavailability of mail services.  \n\nCorrect configuration of this control will prevent unplanned outages due to being enabled.  On occasions when it is needed, care should be taken in process steps to clear the check box upon task completion, so that mail stores are available to users (unmounted mailbox stores are not available to users).",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-MB-405",
+      "title": "The Public Folder Stores must mount at startup.",
+      "description": "Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Public Folder Store data manipulation.  Occasionally, there may be a need to start the server with 'unmounted' data stores, if manual maintenance is being performed on them.  Failure to uncheck the 'do not mount on startup' condition will result in unavailability of Public Folder services.  \n\nCorrect configuration of this control will prevent unplanned outages due to being enabled.  On occasions when it is needed, care should be taken in process steps to clear the checkbox task completion, so that public folder stores are available to users  (unmounted public folder stores are not available to users).",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-MB-406",
+      "title": "The email server Circular Logging must be disabled.",
+      "description": "Logging provides a history of events performed, and can also provide evidence of tampering or attack.  Failure to create and preserve logs adds to the risk that suspicious events may go unnoticed, or the raise the potential that insufficient history will be available to investigate them.  \n\nThis setting controls how log files are written. If circular logging is enabled, there is one log file for this storage group with a maximum size of (for example, 5MB). Once the size limit has been reached, additional log entries begin overwriting the oldest log entries.  If circular logging is disabled, once a log file reaches the size limit, a new log file is created. \n\nBack-End Servers should not use circular logging.  Logs should be written to a partition separate from the operating system, with log protection and backups being incorporated into the overall System Security plan. \n\nFront-End Servers may opt to use circular logging, as message content is significantly less, and not of a critical nature.",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-MB-407",
+      "title": "Email \"Subject Line\" logging must be enabled.",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.  When \"message tracking\" is enabled, only the sender, recipients, time, and other delivery information are included by default.   Information such as the subject and message body is not included.  \n\nHowever, the absence of the message subject line can make it difficult to locate a specific message in the log unless one knows roughly what time the message was sent.  To simplify searches through these logs, Exchange offers the ability to include the message \"subject line\" in the log files and in the Message Tracking Center display.  This can make it significantly easier to locate a specific Message.  \n\nThis feature creates larger log files and will contain information that may raise privacy and legal concerns - enterprise policy should be consulted before this feature is enabled. Also, since the log files may contain sensitive information in the form of the subject line, the log files will need to be protected, commensurate with the sensitivity level, as the content may be of interest to an attacker.  \n\nFor these reasons, it is recommended that subject logging not be enabled during regular production operations, but instead treat this feature as a diagnostic that can be used if needed. The tradeoff of this is that finding the correct message in the message tracking logs will become more difficult since the administrator will need to search using only the time the message was sent and the message's sender.  This control will have no effect unless Message Tracking is enabled. That said, the setting should be disabled in case message tracking is perchance enabled at a future time.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-MB-408",
+      "title": "Message Tracking Logging must be disabled.",
+      "description": "A message tracking log provides a detailed log of all message activity as messages are transferred to and from a computer running Exchange. Message tracking is available on Hub Transport servers, Edge Transport servers, and Mailbox servers. By default, message tracking is enabled.\nIf events are not recorded it may be difficult or impossible to determine the root cause of system problems or the unauthorized activities of malicious users.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-MB-409",
+      "title": "Queue monitoring must be configured with threshold and action.",
+      "description": "Monitors are automated \"process watchers\" that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed.   Exchange has built-in monitors that enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.  \n\nThis field offers choices of alerts when a 'warning' or 'critical' threshold is reached on the SMTP queue.  A good rule of thumb (default) is to issue warnings when SMTP queue growth exceeds 10 minutes and critical messages when it exceeds 20 minutes, which should only exist occasionally.  Frequent alerts against this counter may indicate a network or other issue (such as inbound SPAMMER traffic) that directly impacts email delivery.   \n\nNotification choices include email alert to an email enabled account, for example, an email Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it.\n   \n\nNote: If a third party application is performing monitoring functions, the reviewer should verify the  application is monitoring correctly and mark the vulnerability N/A.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-MB-410",
+      "title": "Mail must be retained until backups are complete.",
+      "description": "Backup and recovery procedures are an important part of overall system availability and integrity.   Complete backups reduce the chance of accidental deletion of important information, and ensure that complete recoveries are possible.  \n  \nIt is not uncommon for users to receive and delete messages in the scope of a single backup cycle.   This setting ensures at least one backup has been run on the mailbox store before the message physically disappears.  By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-MB-411",
+      "title": "Public Folder stores must be retained until backups are complete.",
+      "description": "Backup and recovery procedures are an important part of overall system availability and integrity.   Complete backups reduce the chance of accidental deletion of important information, and ensure that complete recoveries are possible.  \n  \nIt is not uncommon for users to receive and delete documents in the scope of a single backup cycle.   This setting ensures at least one backup has been run on the folder store before the message physically disappears.  By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-MB-412",
+      "title": "Mailbox database must not be overwritten by a restore.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning configurations.    Unauthorized or accidental restoration of mailbox data risks data loss or corruption.   \n\nThis setting controls whether the mailbox store can be overwritten by a backup, which will cause loss of all information added after the backup was created.  It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterwards.  \n\nDuring production windows, this setting must be disabled.",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-MB-413",
+      "title": "Public Folder database must not be overwritten by a restore.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning configurations.  Unauthorized or accidental restoration of public folder data risks data loss or corruption.  \n\nThis setting controls whether the public folder store can be overwritten by a restore from backup, which will cause loss of all information added after the backup was created.  It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterwards.  \n\nDuring production windows, this setting must be disabled.",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-MB-414",
+      "title": "Mailbox databases must reside on a dedicated partition.",
+      "description": "In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to the host system can most likely lead to a compromise of all applications hosted by the same system.\n\nEmail services should be installed to a discrete set of directories, on a partition that does not host other applications.   Email services should never be installed on a Domain Controller / Directory Services server.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-MB-415",
+      "title": "Email SMTP forwarding must be restricted.",
+      "description": "Auto-forwarding email to external email accounts is prohibited.  Auto-forwarded e-mail to non-CAC enabled e-mail accounts does not meet requirement for digital signature and encryption of CUI and PII IAW DODI 8520.2 (reference ee) and DOD Director for Administration and Management memorandum, \"Safeguarding Against and Responding to the Breach of Personally Identifiable Information\" (reference ttt). ",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_microsoft_exchange_server_2003.json

@@ -0,0 +1,647 @@
+{
+  "name": "stig_microsoft_exchange_server_2003",
+  "date": "2014-08-19",
+  "description": "Guidance for Microsoft Exhange Server 2003 in the Mailbox Server, MTA, and the Client Access (OWA) Server Roles. ",
+  "title": "Microsoft Exchange Server 2003",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-18641",
+      "title": "User mailboxes are hosted on non-Mailbox Server role.",
+      "description": "Separation of roles supports operational security for application as well as human resources.   By isolating a server role such as ‘Mailbox Role’, boundaries that pertain to Mailbox data protection need only be focused in the Mailbox data server.  In this way, any Mailbox-specific attack vectors, protocol traffic requirements are more optimally secured.  Mailbox data repositories should only be hosted on the Mailbox Server Role.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18642",
+      "title": "E-mail Server does not require S/MIME capable clients.",
+      "description": "Identification and Authentication provide the foundation for access control.  The ability for receiving users to authenticate the source of E-Mail messages helps to ensure that they are not FORGED or SPOOFED before they arrive. \n\nMIME (Multipurpose Internet Mail Extensions) is an Internet standard that extends the format of e-mail and other web content to support ASCII and other character sets in both the message and header, text and non-text attachments, and multi-part message bodies.   All human-originating E-Mail messages are transmitted in MIME format. \n\nS/MIME (Secure / Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in MIME.  Participants in S/MIME message exchanges must obtain and install an individual key/certificate from the DoD.  S/MIME clients will require that each participant own a certificate before allowing them to encrypt messages to others.\n\nTo minimize attack vectors revealed by lack of signed or encrypted E-Mail, all clients in the enterprise must be updated to support S/MIME, and all mail servers must require S/MIME capability.",
+      "severity": "high"
+    },
+    {
+      "id": "V-18643",
+      "title": "E-mail user mailboxes do not have Storage Quota Limitations. ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.   These settings control the maximum sizes of a user’s mailbox and the system’s response if these limits are exceeded.   Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable.   There are three controls, which supply graduated levels of opportunity to respond before risking data loss.  \n\nThe first control sends an E-mail warning to users stating that they have exceeded their mailbox quota.  The second level sends the warning, and causes users to receive, but not send, mail.  The third level sends a warning message, and causes users to neither receive nor send mail.   Quota limits should be set as multiples of “Maximum Message Size” to ensure no level is skipped.\n\nAs a practical matter, levels 1 and 2 serve the purpose of prompting users to manage their E-mail.  Level 3 impedes users in their ability to work, and is not required as mail interruption is not acceptable.    User Mailbox Quota limitations are not a substitute for overall disk space monitoring.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18644",
+      "title": "E-mail Public Folders do not have Storage Quota Limitations.",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  These settings control the maximum sizes of a Public Folder and the system’s response if these limits are exceeded. There are two available controls and the system response when the quota has been exceeded. \n\nThe first control sends an E-mail warning to Folder Owners roles alerting them that the folder has exceeded its quota.  The second level prevents posting any additional items to the folder.  \n\nAs a practical matter, level 1 serves the purpose of prompting owners to manage their folders. Level 2 impedes users in their ability to work, and is not required where folder use interruption is not acceptable.   Public Folder Storage Quota Limitations are not a substitute for overall disk space monitoring.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18645",
+      "title": "Public Folders Store storage quota limits are overridden. ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.   Some settings enable more granular control when it is needed for a specific circumstance, however, if a sound strategy is not planned for configuration placement, it increases the risk that system integrity and availability could be compromised.  \n\nThis setting gives the Administrator a choice to either “Use Public Store Defaults”, or choose to override with different values.  If the “Use Public Store Defaults” is chosen, then the Public Folder store’s settings are applied to this folder and the other alert fields in this group are disabled.  \n\nIf  the “Use Public Store Defaults” is NOT selected then ALL of the storage limit controls in the Public Folder store will be ignored for this folder,  and ALL behaviors will then have to be set in this panel and administered separately for this store.  If overrides are needed for a Public Folder, they should be documented in the System Security Plan. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18646",
+      "title": "Mailbox Stores  \"Do Not Mount at Startup\" is enabled. ",
+      "description": "Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Mailbox data manipulation.  Occasionally, there may be a need to start the server with ‘unmounted’ data stores,  if manual maintenance is being performed on them.  Failure to uncheck the ‘do not mount on startup’ condition will result in unavailability of mail services.  \n\nCorrect configuration of this control will prevent unplanned outages due to being enabled.  On occasions when it is needed, care should be taken in process steps to clear the check box upon task completion, so that mail stores are available to users  (unmounted mailbox stores are not available to users).  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18655",
+      "title": "Public Folder Stores \"Do not Mount at Startup\" is enabled.   ",
+      "description": "Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Public Folder Store data manipulation.  Occasionally, there may be a need to start the server with ‘unmounted ’ data stores,  if manual maintenance is being performed on them.  Failure to uncheck the ‘do not mount on startup’ condition will result in unavailability of Public Folder services.  \n\nCorrect configuration of this control will prevent unplanned outages due to being enabled.  On occasions when it is needed, care should be taken in process steps to clear the checkbox task completion, so that public folder stores are available to users  (unmounted public folder stores are not available to users).  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18658",
+      "title": "Public Folder “Send on Behalf of” feature is in use.  ",
+      "description": "The principle of non-repudiation gives a message recipient the assurance that the message can be attributed to the named sender.  If users are allowed to send on behalf of other parties, it introduces risk that receivers may never realize the identity of the actual sender of the message.  This can enable nefarious senders to mask their activities. \n\nThe “Send on Behalf” field should be cleared (messages are not sent on behalf of any party).  While the full “from” field displays both the actual sender as well as who the message is on behalf of, in many instances only the party on whose behalf the message was sent may be seen. \n\nIf “Send on behalf” is used, accounts with the ability should be documented and monitored to ensure this privilege is not being abused.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18660",
+      "title": "Automated Response Messages are Enabled.",
+      "description": "SPAM originators, in an effort to refine mailing lists, sometimes use a technique where they monitor transmissions for automated bounce back messages such as “Out of Office” messages.  Automated messages include such items as Out of Office responses, non-delivery messages, or automated message forwarding.\n\nAutomated bounce back messages can be used by a third party to determine user “liveness” on the server. This can result in the disclosure of active user accounts to third parties, paving the way for possible future attacks.  \n\nMail forwarding is an automated feature that does not provide information to third parties, but it poses a potential risk on networks where classified or confidential information may be sent.  For example, if auto-forwarding is configured, sensitive information sent to this user’s account may automatically be transferred outside the control of the organization.   \n   \nThe “Default” format applies to all domains.  However, if a new format is created and applied to a specific domain, that domain will use the new format's configuration while all other domains (those without specially designated formats) will use the Default format.   Automated messages must be disabled to prevent inadvertent information disclosure about E-mail recipients.     ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18661",
+      "title": "Mailbox server is not protected by E-mail Edge Transport role (E-mail Secure Gateway) performing Global Accept/Deny list filtering. ",
+      "description": "SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers.  Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts.   \n \nThe Global Accept and Deny List settings (sometimes referred to 'Black Lists' and 'White Lists' ) respectively block or admit messages originating from specific sources.   Ideally, 'Black List' filtering is done at the perimeter of the network (using a commercial 'Block List' service), because eliminating threats there prevents them being evaluated inside the enclave where there is more risk they can do harm.  When no commercial 'Block List Service' is employed as the 'Black List', the values configured here perform similar filtering and can be used to supplement the sites identified in the 'Block List Service'.  For example, during a 0-Day threat action, entries can be added,  then removed when the threat is mitigated.   A common practice is to enter the enterprise’s home domain in the 'Global Deny List', at a minimum, as inbound E-mail where a ‘from’ address of the home domain is very likely to be SPOOFED SPAM.  \n\nThe Accept List field (referring to the ‘White List’) overrides both the ‘Deny List’ and the ‘Block List’ Service.  Even if the ‘Block List’ claims that listed domains are spammers, inbound mail will still be received mail from them.  Normally, no entry should appear in the Global Accept List.  \n\nNote:  Use of ‘White List’ entries can inadvertently lead to Denial of Service situations due to inbound messages bypassing the filtering mechanism.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18662",
+      "title": "Mailbox Server is not protected by an Edge Transport Server (E-mail Secure Gateway) performing SPAM evaluation.",
+      "description": "By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment.  SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers.  Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts.   By performing filtering at the perimeter, SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment.  This significantly reduces the attack vector for inbound E-mail-borne SPAM and malware.\n\nSPAM evaluation (heuristic) filters scan inbound email messages for evidence of SPAM and other attacks that primarily use ‘Social Engineering’ techniques.  Upon evaluation, a rating is assigned to each message estimating the likelihood of its being SPAM.  When the message is received in the user’s mailbox, the junk mail filter threshold determines whether the message will be withheld from delivery, delivered to the junk mail folder, or delivered to the user’s inbox. \n\nFor Exchange 2003 servers, Microsoft introduced the Intelligent Message Filter (IMF).  Beginning with Exchange 2003 SP2 it was included as part of the application.   Since that time, however, it is recommended that such filtering occur at the network perimeter.  That said, risk of inbound SPAM can be somewhat mitigated by using the Microsoft IMF on the Exchange 2003 Mail server, even as an interim measure, while planning for a more comprehensive, Edte Transport Server (E-Mail Secure Gateway). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18663",
+      "title": "The Mailbox server is not protected by an Edge Transport Server Role (E-mail Secure Gateway) performing 'Block List' filtering.",
+      "description": "SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers.  Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts.   \n\nIdeally, 'Block List' filtering is done at the perimeter of the network (using a commercial 'Block List' service),   because eliminating threats there prevents them being evaluated inside the enclave where there is more risk they can do harm.    \n\nBlock List Services are fee based data providers that collect the IP addresses of known SPAMmers and other malware purveyors.  Subscribers to these services benefit from more effective SPAM elimination (up to 90% of inbound mail volume) as well as leveraging the E-Mail Administration effort needed to maintain and update larger block lists than a single E-Mail site administrator could conveniently maintain.  Neglecting to specify a 'Block List' would require E-Mail Administrators to manually specify addresses in the ‘Deny List’ field as they are discovered. \n\nThe 'Block List' Services provider will provide a value for this field – usually the DNS suffix for their domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18664",
+      "title": "Mailbox server is not protected by an Edge Transport Server role (E-mail Secure Gateway) performing Block List exception filtering at the perimeter.",
+      "description": "SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers.  Limiting exposure to inbound messages is one type of filtering that can reduce the risk of SPAM and malware impacts.   \n\nIdeally, 'Block List' filtering is done at the perimeter of the network (using a commercial 'Block List' service),   because eliminating threats there prevents them being evaluated inside the enclave where there is more risk they can do harm.  \n\nBlock List Exceptions are used to specify sources that should not be blocked despite their presence in a block list.  Exceptions, if used, should be carefully vetted to ensure they are sources of legitimate email. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18665",
+      "title": "Mailbox Server is not protected by an Edge Transport Server (E-mail Secure Gateway) performing Sender Authentication at the perimeter. ",
+      "description": "Email is only as secure as the recipient.  When the recipient is an E-Mail server accepting inbound messages, authenticating the sender enables the receiver to better assess message quality and to validate the sending domain as authentic.  One or more authentication techniques used in combination can be effective in reducing SPAM, PHISHING, and FORGERY attacks.  \n\nThere are two primary methods of sender authentication; Sender ID Framework (SIDF), and Domain Keys Identified Mail (DKIM).   \n\nThe Sender ID Framework (SIDF) receiver accesses specially formatted DNS records (SPF format) that contain the IP address of authorized sending servers for the sending domain that can be compared to data in the email message header.   Receivers are able to validate the authenticity of the sending domain, eliminate PHISHING SPAM, and can be used in combination with DKIM.  SIDF is a Microsoft creation, and is available on Exchange 2003 Servers. \n\nThe DKIM receiver accesses specially formatted DNS records that contain the Public Key for the sending domain’s authorized outbound mail servers.  The key is used to decrypt the hash in the message header and determine whether the message has been modified.    DKIM is not effective against replay attacks, but can detect forgeries.  Some false positives are possible if interim E-Mail forwarders append text to the message body.  DKIM is a Cisco creation, and is available on most Edge Transport Server (E-mail Secure Gateway) products. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18666",
+      "title": "E-mail Server Global Sending or Receiving message size is set to Unlimited.",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.   Message size limits should be set to 30 megabytes at most, but often are smaller, depending on the organization.  The key point in message size is that it should be set globally, and it should not be set to ‘unlimited’.  \n\nSelecting the “no limit” radio button on either field is likely to result in abuse and can lead to rapid filling of server disk space. \n\nMessage size limits may be applied in Routing Group connectors, SMTP connectors, Public Folders, and on the user account under AD.  Changes at these lower levels are discouraged, as the single global setting is usually sufficient.  This practice prevents conflicts that could impact availability and it  simplifies server administration.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18667",
+      "title": "Sending or Receiving message size is not set to Unlimited on the SMTP virtual server. ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.  E-mail system availability has become a necessary feature in information sharing, and controlling message size limit reduces risk that servers become unavailable due to message size conflicts.  By setting “unlimited” at the virtual server level, it enables the global setting to prevail without being overridden at this level.  The message size limit applies to E-mail and other features that use Simple Message Transfer Protocol (SMTP), such as Public Folders.  \n\nThe default setting of ‘no limit’ at the virtual server level is recommended and should provide sufficient protection against excessively large messages passing through the virtual server.  \n\nMessage size limits may be applied in Virtual Servers, Routing Group connectors, SMTP connectors, Public Folders, and on the user account under Active Directory.  Changes at these lower levels are discouraged, as the single global setting is usually sufficient.  This practice prevents conflicts that could impact availability and it simplifies server administration.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18668",
+      "title": "The SMTP Virtual Server Session Size is not set to \"Unlimited\". ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  This setting controls the maximum SMTP Virtual Server session sizes (inbound and outbound) and applies globally to the Simple Mail Transfer Protocol (SMTP) protocol.   If the session size limit is set too low, the SMTP server may increase the number of sessions spawned, which increases the risk that other set limits will be reached.  Controlling session resource usage is best done by controlling the number of messages in a session.\n\nIt is is recommended that this setting remain at the default of ‘Unlimited’.    ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18669",
+      "title": "The SMTP Virtual Server Message Count Limit is not 20. ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  This setting controls the maximum number of messages allowed in a single SMTP session by breaking large numbers of messages into multiple sessions. This configuration is the preferred place to control session size.   \n",
+      "severity": "low"
+    },
+    {
+      "id": "V-18670",
+      "title": "Message Recipient Count Limit is not limited on the SMTP virtual server. ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  Global Message Recipient Limits determine the total number of recipients that can be addressed on a single message.  At the virtual server level, this field is set to a limited size, and is used to control the maximum number of recipients who will receive a copy of this message at one time. It is intended to improve efficiency by forcing messages sent to a greater number of recipients to be sent out in multiple messages.   \n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18671",
+      "title": "The Global Recipient Count limit is set to “Unlimited”.",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.    The Global Recipient Count limit field is used to control the maximum number of recipients that can be specified in a single message sent from this server. Its primary purpose is to minimize the chance of an internal sender spamming other recipients, since SPAM messages often have a large number of recipients.  SPAM prevention can originate from both outside and inside organizations.  While inbound SPAM is evaluated as it arrives, controls such as this one help prevent SPAM that might originate inside the organization.  \n\nThe Recipient Count Limit is global to the Exchange implementation.  Lower-level refinements are possible; however, in this configuration strategy, setting the value once at the global level ensures a more available system by eliminating potential conflicts among multiple settings.  A value of less than or equal to 5000 is probably larger than is needed for most organizations, but is small enough to minimize usefulness to spammers, and is easily handled by Exchange.  Selecting the “no limit” radio button for this item is likely to result in abuse.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18672",
+      "title": "The Exchange E-mail Services environment is not protected by an Edge Transport Server (E-Mail Secure Gateway) performing Non-existent recipient filtering at the perimeter. ",
+      "description": "SPAM originators, in an effort to refine mailing lists, sometimes use a technique where they first create fictitious names, then monitor rejected E-mails for non-existent recipients.  \nThose not rejected, of course, are deemed to exist, and are therefore used in future SPAM mailings. \n\nTo prevent this disclosure of existing E-Mail accounts to SPAMmers, this feature should not be employed.  Instead, it is recommended that all messages be received, then evaluated and disposed of without enabling the sender to determine recipients that are  existing vs. non-existing.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18673",
+      "title": "The Mailbox server is not protected by having filtered messages archived by the Edge Transport Role server (E-mail Secure Gateway) at the perimeter.",
+      "description": "By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment.  This significantly reduces the attack vector for inbound E-mail-borne SPAM and malware.    \n\nAs messages are filtered, it is prudent to temporarily host them in an archive for evaluation by administrators or users.  The archive can be used to recover messages that might have been inappropriately filtered, preventing data loss, and to provide a base of analysis that can provide future filter refinements.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18674",
+      "title": "The Mailbox server is not protected by having blank sender messages filtered by the Edge Transport Role server (E-mail Secure Gateway)  at the perimeter. ",
+      "description": "By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment.  Anonymous E-mail (messages with blank sender fields) cannot be replied to.   Messages formatted in this way may be attempting to hide their true origin to avoid responses, or to SPAM any receiver with impunity while hiding their source of origination.  \n\nRather than spend resource and risk infection while evaluating them, it is recommended that these messages be filtered immediately upon receipt and not forwarded to end users.    \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18675",
+      "title": "The E-Mail server is not protected by having connections from “Sender Filter” sources dropped by the Edge Transport Server role (E-Mail Secure Gateway) at the perimeter. ",
+      "description": "SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers.  Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts.   \n\nIt is recommended that “drop connections” action be taken when inbound requests are from addresses that match sender filters (such as those on Block List) and be performed in the perimeter network by an E-Mail Secure Gateway server,  because eliminating threats there prevents them being evaluated inside the enclave where there is more risk they can do harm.   If the other party has other messages to send, it must re-initiate the Simple Message Transfer Protocol (SMTP) connection to start sending the next message (as opposed to simply continuing the current connection). This will slow down the rate at which this blocked sender is able to send messages to the server, further mitigating the potential for a Denial of Service attack.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18676",
+      "title": "E-Mail server has unneeded processes or services active.",
+      "description": "Unneeded, but running,  services offer attackers an enhanced attack profile, and attackers are constantly watching to discover open ports with running services.  By analyzing and disabling unneeded services, the associated open ports become unresponsive to outside queries, and servers become more secure as a result.  \n \nExchange 2003 has role-based server deployment to enable protocol path control and logical separation of network traffic types.   \n\nFor example, a server implemented in the Client Access role (i.e., Outlook Web Access [OWA]) is configured and tuned as a web server using web protocols.  A client access server exposes only web protocols (HTTP/HTTPS) enabling System Administrators to optimize the protocol path and disable all services unnecessary for Exchange web services.    Similarly, Back-End servers created to host mailboxes are dedicated to that task, and operate only the services needed for mailbox hosting.  (Back-end servers must also operate some Web services, but only to the degree that Exchange 2003 requires the IIS engine in order to function).   \n\nTo restrict attack vectors available with E-mail message access, the protocols on the E-mail servers should match offerings on the DoD standard desktop deployment.  These include Microsoft Outlook using MAPI, S/MIME enabled clients, and secured connections.  It also includes Outlook via VPN for offsite telework.  Browsers may access OWA provided it uses PKI/CAC access brokered through a reverse proxy Application Server.  \n\nBecause NNTP, POP3, and IMAP4 clients are not included in the standard desktop offering, they must be disabled.  Guidance is not provided for these protocols in this document.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18681",
+      "title": "Unneeded OMA E-mail Web Virtual Directory is not removed.",
+      "description": " To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed.  By default, a virtual directory is installed for OMA, and the Exchange application default has OMA disabled.  If an attacker were to intrude into an Exchange Front-End server and reactivate OMA, this attack vector could once again be open, provided the virtual directory were present.  Once removed, the OMA functionality cannot be used without restoring the virtual directory, not a trivial process. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18682",
+      "title": "Unneeded Active Sync E-mail Web Virtual Directory is not removed.  ",
+      "description": "To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed.  By default, a virtual directory is installed for Active Sync, and the Exchange application default has Active Sync disabled.  If an attacker were to intrude into an Exchange Front-End server and reactivate Active Sync, this attack vector could once again be open, provided the virtual directory were present.  Once removed, the Active Sync functionality cannot be used without restoring the virtual directory, not a trivial process. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18683",
+      "title": "Unneeded \"Public\" E-mail Virtual Directory is not removed. ",
+      "description": " To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed.  By default, a virtual directory is installed for Public Folders.  If an attacker were to intrude into an Exchange Front-End server and be able to access the public folder web site, it would provide an additional attack vector, provided the virtual directory were present.  Once removed, the Public functionality cannot be used without restoring the virtual directory, not a trivial process. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18685",
+      "title": "Connectors are not clearly named as to direction or purpose.    ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.   For connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions made about the completeness of the configuration.  \n\nCollectively,  connectors should account for all connections required for the overall E-Mail topology design.  Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18686",
+      "title": "Message size restrictions are specified on routing group connectors.    ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.   For message size restrictions, multiple places exist to set or override inbound or outbound message size.  Failure to control the configuration strategy can result in loss of data or system availability. \n\nThis setting enables the administrator to control the maximum size of outgoing messages on a Routing Group connector.  It is recommended that, in general, no limits are applied at the connector level.  This is done so that connectors do not end up prohibiting the delivery of messages that would otherwise be permitted by the Exchange configuration at the virtual server level.  Using connectors to control size limits at an enterprise-wide level is discouraged since the limits would need to be applied to every potential connector in order to create an effective enterprise-wide limit.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18687",
+      "title": "The Outbound Delivery Retry Values are not at the Defaults, or do not have alternate values documented in the System Security Plan.",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.   This setting controls the rate at which delivery attempts from the home domain are retried, user notification is issued, and expiration timeout when the message will be discarded.  \n\nIf delivery retry attempts are too frequent, servers will generate network congestion. If too far apart, then messages may remain queued longer than necessary, potentially raising disk resource requirements.    \n\nThe default values of these fields should be adequate for most environments.  Administrators may wish to modify the values as a result, but changes should be documented in the System Security Plan.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18688",
+      "title": "SMTP Maximum Hop Count is not 30.",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.  This setting controls the maximum number of hops (E-mail servers traversed) a message may take as it travels to its destination.  Part of the original Internet protocol implementation, the hop count limit prevents a message being passed in a routing loop indefinitely.  Messages exceeding the maximum hop count are discarded undelivered.  \n\nRecent studies indicate that virtually all messages can be delivered in fewer than 25 hops, well within the current default of 30.   If the hop count is set too low, messages may expire before they reach their destinations.  If set too high, an undeliverable message may cycle between servers, raising the risk of network congestion.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18689",
+      "title": "SMTP Maximum outbound connections are not at 1000, or an alternate value is not documented in System Security Plan.",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  This setting controls the maximum number of simultaneous outbound connections allowed for a given SMTP Virtual Server, and can be used to throttle the SMTP service if resource constraints warrant it.  If the limit is too low, connections may be dropped.  If too high, some domains may use a disproportionate resource share, denying access to other domains.   Appropriate tuning reduces risk of data delay or loss. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18690",
+      "title": "Maximum outbound connection timeout limit is not at 10 minutes or less.  ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.   This configuration controls the number of idle minutes before the connection is dropped.   It works in conjunction with the Maximum Outbound Connections Count setting.\n\nConnections, once established, may incur delays in message transfer.  The default of 10 minutes is a reasonable window in which to resume activities without maintaining idle connections for excessive intervals.   If the timeout period is too long, idle connections may be maintained for unnecessarily long time periods,   preventing new connections from being established.  Sluggish connectivity increases the risk of lost data.  A value of 10 or less is optimal.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18691",
+      "title": "Outbound Connection Limit per Domain Count is not 100 or less.   ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  This configuration controls the maximum number of simultaneous outbound connections from a domain, and works in conjunction with the Maximum Outbound Connections Count setting as a delivery tuning mechanism.   If the limit is too low, connections may be dropped.  If too high, some domains may use a disproportionate resource share, denying access to other domains.   Appropriate tuning reduces risk of data delay or loss. \n\nBy default, a limit of 100 simultaneous outbound connections from a domain should be sufficient.  The value may be adjusted downward if justified by local site conditions.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18692",
+      "title": "Inbound Connection Count Limit is not set to \"Unlimited\". ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  This configuration controls the maximum number of simultaneous inbound connections allowed to the SMTP server.   By default, the number of simultaneous inbound connections is unlimited.  If a limit is set and is too low, the connections pool may get filled.  If attackers perceive there is a limit, they could deny service to the Simple Mail Transfer Protocol (SMTP) server using a limited connection count (set to unlimited), attackers would need many more connections to cause denial of service.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18693",
+      "title": "Maximum Inbound Connection Timeout Limit is not 10 or less.   ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.   This configuration controls the number of idle minutes before the connection is dropped.   It works in conjunction with the Maximum Inbound Connections Count setting.  \n\nConnections, once established, may incur delays in message transfer.  The default of 10 minutes is a reasonable window in which to resume activities without maintaining idle connections for excessive intervals.   If the timeout period is too long, idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established.  Sluggish connectivity increases the risk of lost data.  A value of 10 or less is optimal. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18694",
+      "title": "SMTP Connection Restrictions do not use the \"Deny All\" strategy.  ",
+      "description": "E-mail is only as secure as the recipient.    Recipient SMTP servers that accept messages from all sources provide a way for rogue senders (such as SPAMMERS) or malicious users to insert message batches (that may be SPOOFED or FORGED) into the message transfer path.  This setting controls which IP addresses are allowed to connect to this Virtual Server to download messages. \n\n Two strategies exist for this control, “Deny None” or “Deny All”.  Exceptions can be listed in the form of IP addresses, which can also be wildcarded as subnet groups. \n\nTo significantly reduce the attack vector for unauthorized connections, the “Deny All” approach must be used, stating authorized connections from “only the list below”.   \n\nDepending on the server’s role in the infrastructure, the list of clients or other SMTP servers authorized to connect to this virtual server should be specified.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18695",
+      "title": "SMTP Sender, Recipient, or Connection Filters are not engaged. ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.   Careful tuning reduces the risk that system or network congestion will contribute to availability impacts.  \n\nFilters that govern inbound E-mail evaluation can significantly reduce SPAM, PHISHING, and SPOOFED E-mails.  Messages from blank senders, known SPAMMERS, or 0-day attack modifications must be enabled to be effective. \n\nEven if filtering is not being performed on the Exchange servers, there is no adverse effect from having them enabled (even if no configuration exist for the filter itself).  It may prevent accidental omission in the event that a filter is configured in the future.  If one of the filters does have configuration values, failure to enable the filter will result in no action taken.  This setting should always be enabled.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18696",
+      "title": "ExAdmin Virtual Directory is not Configured for Integrated Windows Authentication.",
+      "description": "Identification and Authentication provide the foundation for access control.  The ExAdmin Virtual Directory is used by the Exchange System Manager to access mailboxes and Public Folders.  This feature controls the authentication method used to connect to this virtual directory. \n\nThis setting should be set to Integrated Windows Authentication only.  Anonymous access provides for no access control of this virtual directory, Basic authentication transmits the password in the clear, and the other methods are not recommended by Microsoft for this control. \n\nFailure to configure this as per the recommendations may result in unrestricted access to this directory, passwords being sent in the clear, and/or the inability to correctly authenticate, depending on which change is made.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18697",
+      "title": "Routing Group is not selected as the SMTP connector scope.",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.   This setting determines which SMTP Servers are permitted to use this SMTP Connector, identifying those for which it is the most efficient link.  Failure to control SMTP network connections risks slow or lost data due to inefficient links between SMTP connections. \n\nSelecting “Entire Organization” allows any computer in the Exchange organization to use this connector. Selecting “Routing Group” means only those members of the connector's routing group may use the connector. Use of the connector should be limited to the Routing Group in order to limit and control general network connectivity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18698",
+      "title": "The SMTP connectors do not specify use of a “Smart Host”.",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.   In the case of identifying a ‘Smart Host’ for the E-Mail environment, the connector level is the preferred location for this configuration because flow control in this routing group will be retained even if future changes occur at the virtual server level.   \n\nA ‘Smart Host’ (Edge Transport Server) Role acts as an Internet Facing Concentrator for other E-mail servers.  Appropriate hardening can be applied to the Edge Transport Server (E-Mail Secure Gateway) role rather than at multiple locations throughout the enterprise.   The ‘Smart Host’ performs all Domain Name Service (DNS) lookups to determine mail routing and offers some proxy-type benefits.  \n\nFailure to identify a ‘Smart Host’ could default to each  E-mail server performing its own lookups (potentially through protective firewalls).   Exchange 2003 servers should not be Internet facing, and should therefore not perform any ‘Smart Host’ functions.  They must, however, be configured to identify the server that is performing the “Smart Host” function.  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18699",
+      "title": "SMTP connectors allow unauthenticated relay.",
+      "description": "Identification and Authentication provide the foundation for access control.  The key to preventing SPAM insertion into the SMTP message transfer path is to require authentication at each ‘hop’ of the journey from sender to receiver.  Allowing unauthenticated relaying on an internal host allows internal users or applications to submit unauthenticated mail messages, a form of internally spoofed SPAM that can be difficult to trace.\n\nAllowing unauthenticated relaying on an “Internet Facing” host would enable any unauthenticated party to use your Exchange Server to resend mail. This practice is often employed by spammers to obfuscate the source of their messages.  Allowing unauthenticated relaying will almost inevitably result in abuse of the relay by spammers and increased load on the connector.  It can also result in the appearance of the host’s domain on Reputation Black Lists. \n\nThis setting controls whether unauthenticated computers are allowed to resend (relay) E-mail messages through this connector to external domains. (Authenticated users and computers can always relay messages regardless of this control's setting.)   It is recommended that no unauthenticated connections be allowed in the SMTP path. ",
+      "severity": "high"
+    },
+    {
+      "id": "V-18700",
+      "title": "SMTP virtual Server does not Restrict Relay Access.  ",
+      "description": "E-mail is only as secure as the recipient.  This control is used to limit the servers that may use this server as a relay.  If an Simple Mail Transport Protocol (SMTP) sender does not have a direct connection to the Internet (for example, an application that produces reports to be E-mailed) then it will need to use an SMTP Virtual Server that does have a path to the Internet (for example, a local E-mail server) as a relay.\n\nSMTP relay functions must be protected so that third parties are not able to hijack a relay service for their own purposes.  Most commonly, hijacking of relays is done by SPAMMERS to disguise the source of their messages, and may also be used to cover the source of more destructive attacks.  \n \nRelays can be restricted in one of three ways; by blocking relays (restrict to a blank list of servers), by restricting use to lists of valid servers, or by restricting use to servers that can authenticate.   A fourth configuration, ‘allow all except the list below’, should never be used.   Because authenticated connections are the most secure for SMTP virtual servers, it is recommended that relays allow only servers that can authenticate.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18701",
+      "title": "“Smart-Host” is specified at the Virtual Server level. ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  This control determines whether the entire Virtual Server routes its outbound Simple Mail Transfer Protocol (SMTP) messages through a single “Smart-Host”.  \n\n“Smart-Hosts” can help secure communication, but configuring the virtual server level to use the same “Smart-Host” can lead to congestion problems and inflexibility. As such, it is recommended that administrators NOT use “Smart-Hosts” at the virtual server level. Instead, use of “Smart-Hosts” should be configured at the SMTP connector level.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18702",
+      "title": "The SMTP Virtual Server performs reverse DNS lookups for anonymous message delivery.",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.  This feature causes the server to use a Directory Naming Service (DNS) lookup to try to resolve the source of incoming E-mail for anonymous messages as part of the delivery feature.  \n\nWhile enabling this feature does not pose an attack hazard, it is recommended that this feature be disabled to avoid impacting resource availability.  It is relatively easy to fool the DNS lookup, and therefore creates unnecessary risk to the E-mail system.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18703",
+      "title": "Virtual Server default outbound security is not anonymous and TLS. ",
+      "description": "Identification and Authentication provide the foundation for access control.  The key to preventing SPAM insertion into the SMTP message transfer path is to require authentication at each ‘hop’ of the journey from sender to receiver.  Failure to authenticate increases risk that an attacker can insert unauthenticated mail messages, a form of internally SPOOFED SPAM that can be difficult to trace.  Encryption ensures confidentiality of data in motion as it traverses network connections.   Failure to specify TLS encryption causes message transfer to be sent unencrypted, (including the authentication password), which makes it susceptible to eavesdropping.  \n\nThis setting controls the default authentication and encryption algorithms used for outbound connections using this connector. (That is, the authentication used when delivering outbound mail to another SMTP Virtual Server.)   Because E-Mail services environments typically support multi-directional message flow at the Connector level, it is preferred that specific requirements be set there, and let this configuration at the Virtual Server level serve as a default.   Authentication type of Anonymous and use of TLS are recommended for this setting. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18704",
+      "title": "The SMTP Virtual Server is configured to perform DNS lookups for anonymous E-mails. ",
+      "description": "E-Mail system availability depends in part on best practices strategies for setting tuning configurations.  This feature causes the server to use a Directory Naming Service (DNS) lookup to try to determine the source of each anonymous E-mail message.    \n\nWhile enabling this feature does not pose an attack hazard, it is recommended that this feature be disabled to avoid impacting resource availability.  \n\nAnonymous E-mail is invariably SPAM and should be filtered when received at the perimeter.  In this context, DNS lookup is not a reliable indicator of perpetrator information, due to its likelihood of SPAM content and therefore likelihood of altered DNS entries.  The DNS lookup result does not add value, and therefore should not be an enabled feature.    \n",
+      "severity": "low"
+    },
+    {
+      "id": "V-18705",
+      "title": "E-mail Server \"Circular Logging\" is not set appropriately.  ",
+      "description": "Logging provides a history of events performed, and can also provide evidence of tampering or attack.  Failure to create and preserve logs adds to the risk that suspicious events may go unnoticed, or the raise the potential that insufficient history will be available to investigate them.  \n\nThis setting controls how log files are written. If circular logging is enabled, there is one log file for this storage group with a maximum size of (for example, 5MB). Once the size limit has been reached, additional log entries begin overwriting the oldest log entries. If circular logging is disabled, once a log file reaches the size limit, a new log file is created. \n\nBack-End Servers should not use circular logging.  Logs should be written to a partition separate from the operating system, with log protection and backups being incorporated into the overall System Security plan. \n\nFront-End Servers may opt to use circular logging, as message content is significantly less, and not of a critical nature.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18706",
+      "title": "E-mail Diagnostic Logging is enabled during production operations.  ",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.   Diagnostic logging, however, characteristically produces large volumes of data and requires care in managing the logs to prevent risk of disk capacity denial of service conditions. \n\nExchange Diagnostic Logging is broken up into 14 main “services” each of which has anywhere from 2 to 26 “categories” of events to be monitored. Moreover, each category may be set to one of four levels of logging: None (logging disabled), Minimum, Medium, and Maximum, depending on how much detail one desires.   The higher the level of detail, the more disk space required to store the audit material.\n\nDiagnostic logging is intended to help administrators debug problems with their systems, not as a general purpose auditing tool. The diagnostic logs collect a great deal of information – diagnostic log files can grow huge very quickly.   Diagnostic logs should be enabled for limited periods of time when attempting to debug relevant pieces of Exchange functionality.  Once debugging has finished, diagnostic logging should be disabled again.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18707",
+      "title": "E-mail “Subject Line” logging is enabled during production operations.  ",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.  When “message tracking” is enabled, only the sender, recipients, time, and other delivery information is included by default.   Information such as the subject and message body is not included.  \n\nHowever, the absence of the message subject line can make it difficult to locate a specific message in the log unless one knows roughly what time the message was sent.  To simplify searches through these logs, Exchange offers the ability to include the message “subject line” in the log files and in the Message Tracking Center display.  This can make it significantly easier to locate a specific Message.  \n\nThis feature creates larger log files and will contain information that may raise privacy and legal concerns - enterprise policy should be consulted before this feature is enabled. Also, since the log files may contain sensitive information in the form of the subject line, the log files will need to be protected, commensurate with the sensitivity level, as the content may be of interest to an attacker.  \n\nFor these reasons, it is recommended that subject logging not be enabled during regular production operations, but instead treat this feature as a diagnostic that can be used if needed. The tradeoff of this is that finding the correct message in the message tracking logs will become more difficult since the administrator will need to search using only the time the message was sent and the message’s sender.  This control will have no effect unless Message Tracking is enabled. That said, the setting should be disabled in case message tracking is perchance enabled at a future time. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18710",
+      "title": "SMTP Virtual Server Audit Records are not directed to a separate partition.  ",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.  This setting controls the location of the SMTP Virtual Server log file.    \n\nBy default, these files will be stored in \\WINNT\\SYSTEM32\\LOGFILES\\SMPTVSx (where x is a number used to distinguish between virtual servers in this organization). The drop-down menu is used to select the format of the log file. The properties button next to this dropdown displays configuration information specific to the type of log format selected, but usually has some control to indicate the log rotation schedule (that is, how often the old log file should be closed and a new log file should be started). \nIt is required that all log files be written to separate partitions from those used by the Exchange Stores and separate also from the Operating System.  Exchange will dismount its stores if it detects that it has run out of disk space, resulting in a complete loss of Exchange services. To minimize the chance of this happening, log files should write to a separate partition so that if the logs fill this partition it will not result in the failure of Exchange.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18711",
+      "title": "Exchange sends fatal errors to Microsoft.",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.   This setting enables an automated log entry to be sent to Microsoft giving general details about the nature and location of the error.   Microsoft, in turn, uses this information to improve the robustness of their product.\n\nWhile this type of debugging information would not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of problems in your Exchange organization. At the very least, it could alert them to (possibly) advantageous timing to mount an attack.  At worst, it may provide them with information as to which aspects of Exchange are causing problems and might be vulnerable (or at least sensitive) to attack.   \n\nAll system errors in Exchange will result in outbound traffic that may be identified by an eavesdropper.  For this reason, the “Report errors to Microsoft” feature must be disabled at all times.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18712",
+      "title": "Disk Space Monitoring is not Configured with Threshold and Action.  ",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.    Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.  If the server were ever to run out of disk space, the server could fail catastrophically, possibly with data loss.\n\nThis field allows the administrator to control notifications when a ‘warning’ or ‘critical’ trigger is issued in response to low disk availability.  A good rule of thumb is to issue warnings when free space falls under 15% and critical messages when it falls under 5% of total disk space. \n\nNotification choices include E-Mail alert to an E-Mail enabled account, for example, an E-Mail Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18713",
+      "title": "CPU Monitoring Notifications are not configured with threshold and action. ",
+      "description": "Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed.      Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.\n\nThis field offers choices of alerts when a ‘warning’ or ‘critical’ threshold is reached on CPU utilization.  A good rule of thumb (default) is to issue warnings when CPU utilization exceeds 70% for a duration of 10 minutes and critical messages when it exceeds 80% for a duration of 10 minutes, which should only exist occasionally.  Frequent alerts against this counter may indicate that additional capacity is needed, or a network or other issue (such as inbound SPAMMER traffic) that directly impacts E-mail delivery.   \n\nCPU availability should be monitored.  If the server were ever to exceed the maximum CPU threshold, the server could effectively experience a denial of service (DOS) condition.  Notification choices include E-Mail alert to an E-Mail enabled account, for example, an E-Mail Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18714",
+      "title": "Virtual memory monitoring notifications are not configured with threshold and action. ",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.    Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.\n\nThis field offers choices of alerts when a ‘warning’ or ‘critical’ threshold is reached on low virtual memory.  A good rule of thumb (default) is to issue warnings when virtual memory is less than 25% for a duration of 3 minutes, and critical messages when less than 10% for a duration of 3 minutes, which should only exist occasionally.  Frequent alerts against this counter may indicate that additional capacity is needed, or a network or other issue (such as inbound SPAMMER traffic) that directly impacts e-mail delivery.   \n\nVirtual Memory availability should be monitored.   Frequent alerts on this counter could indicate that the server is nearing capacity and that load mitigation measures may be needed.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18715",
+      "title": "SMTP Queue Monitor is not configured with a threshold and alert. ",
+      "description": "Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed.   Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.  \n\nThis field offers choices of alerts when a ‘warning’ or ‘critical’ threshold is reached on the SMTP queue.  A good rule of thumb (default) is to issue warnings when SMTP queue growth exceeds 10 minutes and critical messages when it exceeds 20 minutes, which should only exist occasionally.  Frequent alerts against this counter may indicate a network or other issue (such as inbound SPAMMER traffic) that directly impacts E-mail delivery.   \n\nNotification choices include E-Mail alert to an E-Mail enabled account, for example, an E-Mail Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18716",
+      "title": "Windows 2003 Services Monitoring Notifications are not configured with thresholds and actions.",
+      "description": "Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed.    Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.\n\nThis setting allows the administrator to control notifications when a ‘warning’ or ‘critical’ trigger is issued in response to a selected Windows 2003 service being down.   Exchange is dependent on certain Windows services being active:  (Event Log, NT Lan Man (NTLM) Security Support Provider, Remote Procedure Call (RPC), Server, Workstation, Internet Information Service (IIS) Admin Services, and Hypertext Transfer Protocol (HTTP) Secure Sockets Layer (SSL).  Failure in these services will cause Exchange to also fail in some way.   \n\nOnce all the above services have been added, the “When service is not running change state to” field should be set to Critical. The trigger should be “Critical” because, if any of the services that the core Exchange services depend on stop, this will require immediate attention.\n\nNotification choices include E-mail alert to an E-mail enabled account, (for example, an E-mail Administrator), or invoking a script to take other action (for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it).  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18717",
+      "title": "Exchange Core Services Monitors are not configured with threshold and actions.",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.    Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.\n\nThis field allows the administrator to control notifications when a ‘warning’ or ‘critical’ trigger is issued in response to an Exchange Core service being down.  If exchange core services are down, the service status state should be set to critical, as this will require immediate attention.     \n\nNotification choices include E-Mail alert to an E-Mail enabled account, for example, an E-Mail Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it.    \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18719",
+      "title": "Users do not have correct permissions in the Public Virtual Server.",
+      "description": "The principle of Least Privilege ordinarily requires analysis to ensure that users and processes are granted only as much privilege as is required to function effectively, but no additional privileges that could enable mischief, either accidental or intentional.  \n\nThe Pubic Virtual Server enables web access to public folder documents via browser.  This control determines whether users will have read, write, script source access, and/or directory browsing capabilities under this virtual server.  \n\nPublic Virtual Server requires that users have read, write, script source access, and directory browsing permissions since these are required for proper functioning Public Folders access. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18721",
+      "title": "E-mail servers are not protected by an Edge Transport Server role (E-mail Secure Gateway) removing disallowed message attachments at the network perimeter.",
+      "description": "By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the Mail server environment.    Attachments have been known to carry malware, although the file type and malware types have changed over time.\n   \nAttachments must be controlled at the entry point into the E-mail environment to prevent successful attachment-based attacks.   For outbound messages, the entry point is at E-mail creation, for example, in Outlook or Outlook Web Access (OWA).  For inbound messages, it is at the perimeter.  By using this practice, attachments that are disallowed or are found to be malware carriers can be stripped before the attachment is forwarded to the mailbox server.   In the case of 0-day threats, attachment configuration can be modified to add specific attachment types if they are known to be associated with a newly devised attack.  \n\nFor Microsoft E-Mail services, attachments are controlled by the E-mail client applications, in this case OWA or Outlook.  The attachment file types list should be coordinated among other Microsoft client applications, such as OWA or Outlook, and with other E-mail services that may act upon message attachments, such as a perimeter-based attachment filter used by a non-Microsoft product.    ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18723",
+      "title": "Mailboxes and messages are not retained until backups are complete. ",
+      "description": "Backup and recovery procedures are an important part of overall system availability and integrity.   Complete backups reduce the chance of accidental deletion of important information, and ensure that complete recoveries are possible.  \n  \nIt is not uncommon for users to receive and delete messages in the scope of a single backup cycle.   This setting ensures that at least one backup has been run on the mailbox store before the message physically disappears.  By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18724",
+      "title": "Public Folder stores and documents are not retained until backups are complete. ",
+      "description": "Backup and recovery procedures are an important part of overall system availability and integrity.   Complete backups reduce the chance of accidental deletion of important information, and ensure that complete recoveries are possible.  \n  \nIt is not uncommon for users to receive and delete documents in the scope of a single backup cycle.   This setting ensures that at least one backup has been run on the folder store before the message physically disappears.  By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18725",
+      "title": "Mailbox Stores Restore Overwrite is enabled. ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.    Unauthorized or accidental restoration of mailbox data risks data loss or corruption.   \n\nThis setting controls whether the mailbox store can be overwritten by a backup, which will cause loss of all information added after the backup was created.  It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterwards.  \n\nDuring production windows, this setting must be disabled.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18726",
+      "title": "Public Folder Stores Restore Overwrite is enabled.  ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.  Unauthorized or accidental restoration of public folder data risks data loss or corruption.  \n\nThis setting controls whether the public folder store can be overwritten by a restore from backup, which will cause loss of all information added after the backup was created.  It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterwards.  \n\nDuring production windows, this setting must be disabled.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18727",
+      "title": "E-mail message copies are not archived. ",
+      "description": "For E-mail environments with sufficiently sensitive requirements (either legal or data classification), local e-mail policy may require that all messages sent or received from a given server be preserved.  If local policy requires it for historical or litigation purposes, this feature enables Exchange 2003 to retain a full copy of each message that is received by or sent from this mailbox store. \n\nAdditional setup is also needed, in that a user, distribution list, contact, or Public Folder to whom all messages will be copied, must be selected.  Also known as “Journaling”, this setting is used to provide a “paper trail” of all correspondence that passes through the server.   Journaled messages should always be stored on a separate dedicated journaling server, with protections similar to those granted log and audit files.   The System Security plan should document the remote location, user account, and mailbox store that is used to host the message copy data.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18731",
+      "title": "E-mail application installation is sharing a partition with another application.",
+      "description": "In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to the host system can most likely lead to a compromise of all applications hosted by the same system.\n\nE-Mail services should be installed to a descrete set of directories, on a partition that does not host other applications.   E-Mail services should never be installed on a Domain Controller / Directory Services server.  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18732",
+      "title": "Audit data is sharing directories or partitions with the E-mail application.",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.   Audit log content must always be considered sensitive, and in need of protection.   \n\nSuccessful exploit of an application server vulnerability may well be logged by monitoring or audit processes when it occurs.  By writing log and audit data to a separate directory or partition where separate security contexts protect them, it offers the ability to protect this information from being modified or removed by the exploit mechanism.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18733",
+      "title": "E-mail web applications are operating on non-standard ports. ",
+      "description": "PPSM Standard defined ports and protocols must be used for all Exchange services.  The standard port for HTTP connections is 80 and the standard port for HTTPS\nConnections is 443.  \n\nChanging the ports to non-standard values provides only temporary and limited protection against automated attacks since these attacks will not likely connect to the custom port.  However, a determined attacker may still be able to determine which ports are used for the HTTP and HTTPS protocols by performing a comprehensive port scan.  \n\nNegative impacts to using nonstandard ports include complexity for the system administrator, custom configurations for connecting clients, risk of port conflict with non-exchange applications, and risk of incompatibility with standard port monitoring applications. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18734",
+      "title": "E-mail SMTP services are using Non-PPSM compliant ports. ",
+      "description": "Standard defined ports and protocols should be used for all Exchange services.  \nThe standard port for regular SMTP connections is 25.  \n\nChanging the ports to non-standard values provides only temporary and limited protection against automated attacks since these attacks will not connect to the custom port.  A determined attacker may still be able to determine which ports are used for the SMTP by performing a comprehensive port scan\n\nNegative impacts of using non-standard ports include complexity for the system administrator, custom configurations for connecting clients, risk of port conflict with non-exchange applications, and risk of incompatibility with standard port monitoring applications.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18735",
+      "title": "SMTP Virtual Server is not bound to the PPSM Standard Port.",
+      "description": "PPSM Standard defined ports and protocols must be used for all Exchange services.  \nThe default port for SMTP connections is 25.  \n\nChanging the ports to non-standard values provides only temporary and limited protection against automated attacks since these attacks will not likely connect to the custom port.  A determined attacker may still be able to determine which ports are used for the SMTP by performing a comprehensive port scan.\n\nNegative impacts of using non-standard ports include complexity for the system administrator, custom configurations required for connecting clients, risk of port conflict with non-exchange applications, and risk of incompatibility with port monitoring applications.  Since changing the port introduces a large amount of complexity for a relatively small gain, the DoD PPSM requires that standard SMTP ports be used.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18741",
+      "title": "E-mail software is not monitored for change on INFOCON frequency schedule.",
+      "description": "The INFOCON system provides a framework within which the Commander USSTRATCOM regional commanders, service chiefs, base/post/camp/station/vessel commanders, or agency directors can increase the measurable readiness of their networks to match operational priorities.   The readiness strategy provides the ability to continuously maintain and sustain one’s own information systems and networks throughout their schedule of deployments, exercises and operational readiness life cycle independent of network attacks or threats. The system provides a framework of prescribed actions and cycles necessary for reestablishing the confidence level and security of information systems for the commander and thereby supporting the entire Global Information Grid (GIG) (SD 527-1 Purpose).\n\nThe Exchange software files and directories as well as the files and directories of dependent applications are vulnerable to unauthorized changes if not adequately protected.  An unauthorized change could affect the integrity or availability of e-mail services overall.  For this reason, all application software installations must monitor for change against a software baseline that is preserved when installed, and updated periodically as patches or upgrades are installed.  Automated and manual schedules for  software change monitoring must be compliant with SD527-1 frequencies.   ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18742",
+      "title": "Security support data or process is sharing a directory or partition with Exchange. ",
+      "description": "The Security Support Structure is a security control function or service provided by an external system or application.  For example, a Windows Domain Controller that provides Identification and Authentication Services (Active Directory) may be at risk of compromise if a co-resident application becomes compromised.  The attacker can then use another system to control access to other parts of the domain.   \n\nThe vulnerabilities and associated risk of Exchange 2003 installed on a system that provides a security support structure is significantly higher than when installed with other functions that do not provide security support.   For this reason, applications such as Exchange 2003 should never be co-resident on a server with Active Directory.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18743",
+      "title": "Exchange software baseline copy does not exist.     ",
+      "description": "Exchange 2003 software, as with other application software installed on a host system, must be included in a system baseline record and periodically reviewed, otherwise unauthorized changes to the software may not be discovered.  This effort is a vital step to securing the host and the applications,  as it is the only method that may provide the ability to detect and recover from otherwise undetected changes, such as those that result from worm or bot intrusions. \n\nThe Exchange 2003 software and configuration baseline is created and maintained for comparison during scanning efforts.  Operational procedures must include baseline updates as part of configuration management tasks that change the software and configuration.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18744",
+      "title": "E-mail Public Folders do not require S/MIME capable clients. ",
+      "description": "Identification and Authentication provide the foundation for access control.  The ability for receiving users to authenticate the source of Public Folder messages helps to ensure that they are not FORGED or SPOOFED before they arrive.  \n\nMIME (Multipurpose Internet Mail Extensions) is an Internet standard that extends the format of E-mail and other web content to support ASCII and other character sets in both the message and header, text and non-text attachments, and multi-part message bodies.   All human-originating E-Mail messages are transmitted in MIME format. \n\nS/MIME (Secure / Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in MIME.  Participants in S/MIME message exchanges must obtain and install an individual key/certificate from the DoD.  S/MIME clients will require that each participant own a certificate before allowing message encrypting to others.\n\nTo minimize attack vectors revealed by lack of signed or encrypted documents, all clients in the enterprise must be updated to support S/MIME, and all mail servers must require S/MIME capability.",
+      "severity": "high"
+    },
+    {
+      "id": "V-18745",
+      "title": "OWA Virtual Server has Forms-Based Authentication enabled.  ",
+      "description": "Identification and Authentication provide the foundation for access control.  Access to E-Mail services applications in the DoD require authentication using DoD Public Key Infrastructure (PKI) certificates.  The Exchange Virtual Server, which operates Outlook Web Access (OWA), is used to enable web access to user E-mail mailboxes.  This setting controls whether Forms-based login should be used by the OWA web site. \n\nForms-based login enables a user to enter an Account and Password for the web session.   The form stores the username and password information in browser cookies, and enables the user’s mailbox server to be located without user participation.  The cookies persist throughout the OWA session after which they are destroyed. \n\nBecause the DoD requires Common Access Card (CAC)-based authentication to applications, OWA access must be brokered through a an application proxy (for example, Internet Security and Acceleration [ISA]), which performs CAC authentication using a proxy-hosted OWA form.  The authenticated request is then forwarded directly to OWA, where authentication is repeated without requiring the user to repeat authentication steps.  For this scenario to work, the Application Proxy server is must have Forms-based authentication enabled, and Exchange 2003 must have Forms-based Authentication disabled.  \n\nIf Forms-based Authentication is enabled on the Exchange 2003 Front End server, it is evidence that the application proxy server is either not correctly configured, or it may be missing.",
+      "severity": "high"
+    },
+    {
+      "id": "V-18759",
+      "title": "Default web site allows anonymous access. ",
+      "description": "The Default Web site is the virtual server on which all Exchange virtual directories reside. This feature controls the authentication method used to connect to this virtual server and its virtual directories. \nEnsure that this is set to Integrated Windows Authentication only. Anonymous access\nprovides for no access control of this virtual server, Basic Authentication transmits the password in the clear and risks exposure, and the other methods are not recommended by Microsoft for this control. Failure to configure this as per the recommendation may result in unrestricted access to this virtual server, passwords being sent in the clear, and/or the inability to correctly authenticate, depending on which change is made.\n\nBecause CAC authentication will be required and configured via a proxy server such as ISA, settings in this area must assume the presence of an application proxy (such as ISA) between the Public Internet and the Exchange Client Access (Front End) server role.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18760",
+      "title": "OWA does not require only Integrated Windows Authentication. ",
+      "description": "Identification and Authentication provide the foundation for access control.  Access to E-mail services applications in the DoD require authentication using DoD Public Key Infrastructure (PKI) certificates.  \n\nThe Exchange Virtual Server, which controls Outlook Web Access (OWA), is used to link Web Access for user E-mail accounts to the Exchange Mailbox store.  OWA is designed to provide much of the same functionality provided by using an Outlook client, but through a web browser. This setting controls the authentication method used to connect to this virtual server.\n\nOWA does not natively provide Common Access Card (CAC)-Authentication ability.   For this reason, access to OWA must be brokered by an application proxy authentication point where CAC (certificate) authentication is available for Internet-based access to E-Mail services.   It is the proxy server that must authenticate the user’s membership in domain directory services (for example, Microsoft Active Directory) before establishing an authenticated connection to the OWA server.  For this reason, only Integrated Windows Authentication should be selected as the authentication method at this point in the process. ",
+      "severity": "high"
+    },
+    {
+      "id": "V-18762",
+      "title": "One or more SMTP Virtual Servers do not have a Valid Certificate. ",
+      "description": "Server certificates are required for many security features in Exchange, and without them the server cannot engage in many forms of secure communication. \n\nCertificates must be manually installed on each virtual server. This means that installing a certificate on one SMTP Virtual Server does not give other SMTP Virtual Servers (or virtual servers of any other protocol) access to this certificate. However, once a certificate is installed on one virtual server, any other virtual server (regardless of protocol used) may easily be configured to use this certificate by selecting “Assign an existing certificate” in the first page of the Wizard.\n\nInstall certificates on this virtual server. Without it, many other recommendations in this\ndocument concerning secure communication will be impossible. For highest security\nassurance, each virtual server should have its own certificate that it does not share with other servers. This reduces the damage due to server compromises and provides per-server identification.\n\nFailure to implement this recommendation makes it virtually impossible to secure Exchange's communications. Use of any virtual server that has not been given a certificate should be considered a highly insecure action.\n",
+      "severity": "high"
+    },
+    {
+      "id": "V-18763",
+      "title": "Audit Records do not contain all required fields.   ",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.   This item declares the fields that must be available in audit log file records in order to adequately research events that are logged. \n\nAudit records should include the following fields to supply useful event accounting: \n\n•\tAccount\n•\tEvent Code and Type\n•\tSuccess or Failure Indication\n•\tTime/date \n•\tInterface IP address \n•\tManufacturer-specific event name \n•\tSource and destination IP addresses \n•\tSource and destination port numbers \n•\tNetwork Protocol",
+      "severity": "low"
+    },
+    {
+      "id": "V-18767",
+      "title": "The “Disable Server Monitoring” feature is enabled.",
+      "description": "Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed.    This setting controls whether all monitoring processes on this server are enabled or disabled. \n\nMonitoring should never be disabled on the server during production hours.  The processing cycles needed for monitoring should be incorporated into server sizing.  If the configuration disables monitoring, it stops Exchange's built in safety checks to warn the administrators of malfunctions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18770",
+      "title": "SMTP Virtual Server Auditing is not active.",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.  This setting controls the creation and format of log files used to monitor the interaction between this SMTP Virtual Server and other SMTP hosts.   ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18780",
+      "title": "Exchange Server is not protected by an Edge Transport Server (E-mail Secure Gateway) that performs Anonymous Connections interaction with Internet-based E-mail servers.  ",
+      "description": "E-mail is only as secure as the recipient.  By ensuring secured connections for all Simple Mail Transfer Protocol (SMTP) servers along the message transfer path, risk of “Anonymous” message transfers by rogue servers is reduced.   If all message transfers were authenticated from server to server, most SPAM would be eliminated, because anonymous spammers would be more readily traceable.    \n\nHowever, the ability to authenticate a sender from another domain will not be possible until a common authentication method exists between the receiving domain and all of the sending domains that might wish to correspond.   For that reason, the Edge Transport Server role (E-Mail Secure Gateway) should be the only role enabled for Anonymous connections (because it will also perform the sanitization steps) and all internal E-mail application server roles must authenticate to each other.    \n\nThis setting controls the authentication method required to allow connection and message transfer to this virtual server (recipient).  Authentication options include Anonymous, Basic authentication (with clear text password), and Integrated Windows Authentication.  \n\nAnonymous requires no authentication, and is therefore not acceptable.  NT Lan Manager, or NTLM, (Integrated Windows Authentication checkbox) is negotiated, does not provide encryption of message bodies, and cannot sufficiently secure the connection in Exchange 2003.  Risks include the potential of allowing message content to be sniffed over the wire.  \n\n\"Basic authentication\" and \"Require SSL/TLS\" should be selected in this panel.    The use of SSL/TLS not only protects the username and password during authentication, but encrypts the mail messages as they are being transmitted, preventing eavesdroppers from reading messages.  All Exchange 2003 servers should belong to this category. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18782",
+      "title": "SMTP Virtual Servers do not Require Secure Channels and Encryption. ",
+      "description": "The Simple Mail Transfer Protocol (SMTP) Virtual Server is used by the Exchange System Manager to send and receive messages from server to server using SMTP protocol.  This setting controls the encryption strength used for client connections to the SMTP Virtual Server.  With this feature enabled, only clients capable of supporting secure communications will be able to send mail using this SMTP server.  Where secure channels are required, 128 bit encryption can also be selected. \n\nThe use of secure communication prevents eavesdroppers from reading or modifying communications between mail clients and servers.    While sensitive message bodies should be encrypted by the sender at the client, requiring a secure connection from the client to the server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.  \n\nIndividually, channel security and encryption have been compromised by attackers.  Used together, E-mail becomes a more difficult target, and security is heightened.  Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between the client and server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18784",
+      "title": "SMTP Connectors perform outbound anonymous connections. ",
+      "description": "Identification and Authentication provide the foundation for access control.  The key to preventing SPAM insertion into the SMTP message transfer path is to require authentication at each ‘hop’ of the journey from sender to receiver.  Failure to authenticate increases risk that an attacker can insert unauthenticated mail messages, a form of internally SPOOFED SPAM that can be difficult to trace.  Encryption ensures confidentiality of data in motion as it traverses network connections.   Failure to specify TLS encryption causes message transfer to be sent unencrypted, (including the authentication password), which makes it susceptible to eavesdropping.  \n\nThis setting controls the authentication and encryption algorithms used for outbound connections using this connector. (That is, the authentication used when delivering outbound mail to another SMTP Virtual Server.) \n\nWhen the SMTP connectors send messages from a locally controlled (internal to the organization) connector, Basic authentication and TLS should be used by the initiating end of the connection. \n\nBecause no Exchange 2003 servers should directly send to remote SMTP virtual servers, all SMTP outbound connectors should be secured in this way, including the outermost connectors, which should ideally be sending to an Edge Transport Server Role (E-mail Secure Gateway) at the enclave perimeter.",
+      "severity": "high"
+    },
+    {
+      "id": "V-18786",
+      "title": "Public Folder access does not require secure channels and encryption. ",
+      "description": "Failure to require secure connections on a web site increases the potential for unintended decryption and data loss.  This setting controls whether client machines should be forced to use secure channels to communicate with this virtual directory.  If this feature is enabled, clients will only be able to communicate with the directory if they are capable of supporting secure communication with the server. If secure channels are required, the server can also require the channel to be strongly secured by requiring Federal Information Processing Standard (FIPS) 140-2 encryption.\n\nIf Public Folders / Web is approved for use, secure channels and FIPS level encryption are required, as well as appropriate certificate setting. The use of secure communication prevents eavesdroppers from reading or modifying communications between servers and clients.   The network and DMZ STIG identify criteria for OWA and Public Folder configuration in the network, including CAC enabled pre-authentication through an application firewall proxy, such as Microsoft ISA.\n\nNote: if Public Folder is not approved for use, this control is not applicable and the Public Folder virtual directory should be removed to eliminate the possibility of attack through this vector.",
+      "severity": "high"
+    },
+    {
+      "id": "V-18787",
+      "title": "Outlook Web Access (OWA) does not require secure channels and encryption. ",
+      "description": "Failure to require secure connections on a web site increases the potential for unintended decryption and data loss.  This setting controls whether client machines should be forced to use secure channels to communicate with this virtual directory.  If this feature is enabled, clients will only be able to communicate with the directory if they are capable of supporting secure communication with the server. If secure channels are required, the server can also require the channel to be strongly secure by requiring FIPS 140-2 encryption.\n\nIf Outlook Web Access is approved for use, secure channels and FIPS level encryption are required, as well as appropriate certificate setting. The use of secure communication prevents eavesdroppers from reading or modifying communications between servers and clients.   The network and DMZ STIG identify criteria for OWA and Public Folder configuration in the network, including CAC enabled pre-authentication through an application firewall proxy, such as Microsoft ISA.\n\nNote: if  OWA is not approved for use, this control is not applicable and the OWA virtual directory should be removed to eliminate the possibility of attack through this vector.",
+      "severity": "high"
+    },
+    {
+      "id": "V-18788",
+      "title": "ExAdmin is configured for Secure Channels and Encryption. ",
+      "description": "ExAdmin Virtual Directory is used by the Exchange System Manager to access mailboxes and Public Folders.   Users do not directly access the ExAdmin Virtual Directory. \n\nThis feature controls the security setting used to determine whether client machines should be required to connect to this virtual directory using secure channels and encryption.  \n\nThe services that use the ExAdmin Virtual Directory do not support the use of secure channels.  Secure channels should not be configured on this virtual directory, as it will effectively disable the Exchange Mail and Public Folder functionality.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18792",
+      "title": "SMTP service banner response reveals configuration details.",
+      "description": "Automated connection responses occur as a result of FTP or Telnet connections, when  connecting to those services.  They report a successful connection by greeting the connecting client, stating the name, release level, and (often) additional information regarding the responding product.   While useful to the connecting client, connection responses can also be used by a third party to determine operating system (OS) or product release levels on the target server. The result can include disclosure of configuration information to third parties, paving the way for possible future attacks.   \nFor example, when querying the SMTP service on port 25, the default response looks similar to this one:  \n\n220 exchange.mydomain.org Microsoft ESMTP MAIL Service, Version: 6.0.3790.211 ready at Wed, 2 Feb 2005 23:40:00 -0500\n\nChanging the response to hide local configuration details reduces the attack profile of the target.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18795",
+      "title": "E-mail Services accounts are not restricted to named services.",
+      "description": "Applications introduce some of the most common database attack avenues, and can provide a pathway for an unlimited number of malicious users to access sensitive data.  An account responsible for Service execution, if compromised, may subject the data to unauthorized exposure if it is granted more privileges than necessary.  \n\nTypically, service accounts must run only their designated services, and must not be shared with other applications or people.  Audit Log Monitoring can then assume an ‘expected’ set of activities for each service account, and administrators can more readily recognize events that are unexpected.  A discrete history of account activity is valuable if an attack of the host system needs to be investigated.  If accounts are shared among multiple services or people, it increases the risk that firewall Administrators will not have an accurate history for investigation and troubleshooting purposes.\n\nIn the case of Microsoft Exchange Server 2003, attempting to run Exchange services on an alternate service account (rather than the default SYSTEM account) is not a supported Microsoft configuration.  Due to the nature of the Exchange services access required within the server and the network, Exchange 2003 services must run under the Microsoft Windows SYSTEM account. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18796",
+      "title": "E-Mail service accounts are not operating at least privilege.  ",
+      "description": "Good security practice demands both the separation of duties and the assignment of least privilege.  Role Based Access Control (RBAC) is the most accepted method for meeting these two criteria.  A securely designed E-Mail Services implementation includes the definition of E-mail Roles (Servers and services, Users, Administrators, Installers) based on functional requirements for each, then assigning the fewest possible privileges to these roles.  Roles are then assigned to people or services based on the application functions they are required to perform.\n\nIn the case of Microsoft Exchange Server 2003, attempting to run Exchange services on an alternate service account (rather than the default SYSTEM account) is not a supported Microsoft configuration.  Due to the nature of the Exchange services access required within the server and the network, Exchange 2003 services must run under the Microsoft Windows SYSTEM account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18799",
+      "title": "E-mail restore permissions are not restricted to E-mail administrators.    ",
+      "description": "Good security practice demands both the separation of duties and the assignment of least privilege.  Role Based Access Control (RBAC) is the most accepted method for meeting these two criteria.\n\nThe right to restore e-mail applications or data following a service interruption must align with the E-mail Installation and E-mail Administration role, excluding all other user roles.  Because this elevated privilege has the ability to change the application functionality or data from its initial version, it must be carefully assigned, monitored, and controlled.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18801",
+      "title": "Services permissions do not reflect least privilege.",
+      "description": "Good security practice demands both the separation of duties and the assignment of least privilege.  Role Based Access Control (RBAC) is the most accepted method for meeting these two criteria. A securely designed E-mail Services Implementation includes the definition of E-mail Roles (Servers and services, Users, Administrators, Installers) based on functions required by each, then assigning the fewest privileges to these roles.  Roles are then assigned to people or services on the application functions they are required to perform.\n\nThe Exchange GPO templates available from Microsoft enable the E-mail Administrator to easily set a Baseline Security Policy that hardens services permissions.  Installations configured without use of policy templates must nevertheless meet vendor recommended minimums for service protection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18802",
+      "title": "Exchange application permissions are not at vendor recommended settings.",
+      "description": "Default product installations may provide more generous permissions than are necessary to run the application.  By examining and tailoring permissions to more closely provide the least amount of privilege possible, attack vectors that align with user permissions are less likely to access more highly secured areas.  \n\nVendor-supplied policies are available to assist in further hardening the permissions set for Exchange.  Application file permissions on Exchange 2003 servers can be set by importing the group policy for Exchange Back-End or Front-End servers.  To the extent of file permissions, both policies set the same directory permissions as shown here.   ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18803",
+      "title": "Scripts are permitted to execute in the OWA Virtual Server. ",
+      "description": "Scripts on virtual servers are a frequent cause of server compromises.  Since this virtual (web) server is the primary interface between Exchange and the web, it is particularly at risk of compromise.  Therefore, attack vectors via scripts and executables running on the server, should be minimized.\n\nThe Exchange Virtual Server enables web access (OWA) for user mailbox stores. It is designed to provide much of the same functionality as the Outlook client, but through a web browser. \n\nThis control allows the administrator to specify whether scripts and/or executables may be run on this virtual server.  Scripts and executables should be denied permissions to run, eliminating this attack vector from the security profile.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18804",
+      "title": "Scripts are permitted to execute in the Public Folder web server.",
+      "description": "Scripts on virtual servers are a frequent cause of server compromises.  Since this virtual (web) server is the primary interface between Exchange and the web, it is particularly at risk of compromise.  Therefore, attack vectors via scripts and executables running on the server, should be minimized.  The Public Virtual Server enables web access for shared public folders.   \n\nThis control allows the administrator to specify whether scripts and/or executables may be run on this virtual server.  Scripts and executables should be denied permissions to run on this server, eliminating this attack vector from the security profile.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18805",
+      "title": "Scripts are Permitted to Execute in the ExAdmin Virtual Server.",
+      "description": "The ExAdmin Virtual Server is used by the Exchange System Manager to access mailboxes and Public Folders. As such, it is a required part of the Exchange application.  The Exchange System Manager is a central part of the Exchange application and without these capabilities it will be unable to function properly.\n\nScripts on servers are a frequent cause of server compromises.  Since virtual servers are the primary interface between Exchange and the web, they are particularly at risk of compromise.  Therefore, attack vectors via scripts and executables running on the server should be minimized.\n\nThe ExAdmin Virtual Server is used by the Exchange System Manager to access mailboxes and Public Folders.  This control allows the administrator to specify whether scripts and/or executables may be run on this virtual server.\n\nScripts and executables should be denied the ability to run on this server.   The Exchange System Manager is the only entity that interfaces with it, and since the default provides all of the capabilities needed, there should be no reason to change it. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18806",
+      "title": "Users do not have correct permissions in the OWA Virtual Server.",
+      "description": "The principle of Least Privilege ordinarily requires analysis to ensure that users and processes are granted only as much privilege as is required to function effectively, but no additional privileges that could enable mischief, either accidental or intentional.  \n\nThe Exchange Virtual Server (OWA) enables web access for user E-mail mailboxes, however, users to not access the virtual server directly.  This control determines whether users will have read, write, script source access, and/or directory browsing capabilities under this virtual server.  \n\nThe OWA Virtual Server requires that users have read, write, script source access, and directory browsing permissions since these are required for the proper functioning of OWA.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18807",
+      "title": "ExAdmin does not have correct permissions in the ExAdmin Virtual Server.",
+      "description": "The principle of Least Privilege ordinarily requires analysis to ensure that users and processes are granted only as much privilege as is required to function effectively, but no additional privileges that could enable mischief, either accidental or intentional.  \n\nThe ExAdmin Virtual Directory enables web access to E-mail and public folder documents for the Exchange 2003 System Manager.  No users access this part of the application.  This control determines whether the ExAdmin user will have read, write, script source access, and/or directory browsing capabilities under this virtual server.  \n\nExAdmin requires read, write, script source access, and directory browsing permissions since these are required for all of Exchange Web access. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18812",
+      "title": "Exchange application memory is not zeroed out after message deletion.",
+      "description": "Residual data left in memory after a transaction is completed adds risk that it can be used for malicious purposes in the event that access to the data is achieved.  Applications may perform ‘logical delete’ functions, which make the data invisible to the application user, but in fact leave it resident in memory (recoverable, for example, by a forensics tool).  While not malicious, it has the effect of sacrificing security for performance.  \n\nThis feature enables overwrite of memory storage before reuse to negate the potential disclosure of sensitive information that may reside in reallocated memory space.  This means that by the time the memory is returned to the operating system, it essentially no longer contains any information that would allow the message to be retrieved.\n\nUsing this feature may make batch message deletion more time consuming (the server must actually overwrite the entire message).  However, off-hours process performance degradation is not likely to be visible to users.   Performance degradation should not be used as a reason to disable this feature, as the security benefit outweighs the risk.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18818",
+      "title": "E-mail Services are not protected by having an Edge Transport Server (E-mail Secure Gateway) performing outbound message signing at the perimeter. ",
+      "description": "Individual messages can be protected by requiring message signing at the creation point (Outlook), at the originator’s discretion, enabling integrity protection for their messages.  However, messages can also be created by report generators and other applications using automated processes that do not typically sign messages.  \n\nBy signing outbound messages as they exit into the public Internet, the sending SMTP server gives all receivers the opportunity to authenticate the sending domain and server as authentic.  (using the DNS-based DKIM record), and validate the message content as unaltered in transit (using the DKIM public key to rehash).   In this way, forgeries are prevented, SPAMMERs are more easily tracked.   To be effective, it should be noted that unless both senders and receivers participate, sender authentication techniques are of limited effectiveness.  \n\nFor receivers not configured to recognize signed messages, there is no impact to processing – they default to treating the messages as if from anonymous sender origin, and examine it with the evaluation methods that are available. \n\nThe DKIM (Domain Keys Identified Mail) process is not part of Exchange 2003 functionality; so inbound messages that reach an Exchange server as the first receiving touchpoint will not be able to perform this type of sender authentication.  However, most e-mail Secure Gateway products now offer this feature.  \n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18819",
+      "title": "E-Mail audit trails are not protected against unauthorized access.  ",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability.   Audit log content must always be considered sensitive, and in need of protection.  Audit data available for modification by a malicious user can be altered to conceal malicious activity.  Audit data might also provide a means for the malicious user to plan unauthorized activities that exploit weaknesses.\n  \nThe contents of audit logs are protected against unauthorized access, modification, or deletion. Only authorized auditors and the audit functions should be granted Read and Write to audit log data. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18820",
+      "title": "E-mail servers do not have E-mail aware virus protection.   ",
+      "description": "With the proliferation of trojans, viruses, and SPAM attaching themselves to E-Mail messages (or attachments), it is necessary to have capable E-Mail Aware Anti-Virus (AV) products to scan messages and identify any resident malware.   Because E-Mail messages and their attachments are formatted to the MIME standard, a flat-file AV scanning engine is not suitable for scanning E-Mail message stores.  \n\nE-mail aware Anti-Virus engines must use AntiVirus Application Program Interface (AVAPI) version 2.5 or higher, which is able to scan E-Mail content safely.  Competent E-Mail scanners will have the ability to scan mail stores, attachments (including zip or other archive files) and mail queues, and to issue warnings or alerts if malware is detected.  As with other AV products, a necessary feature to include is the ability for automatic updates.",
+      "severity": "high"
+    },
+    {
+      "id": "V-19186",
+      "title": "Mailbox access control mechanisms are not audited for changes.  ",
+      "description": "Unauthorized or malicious data changes can compromise the integrity and usefulness of the data,   Automated attacks or malicious users with elevated privileges have the ability to affect change using the same mechanisms as E-mail administrators.  Auditing changes to access mechanisms supports accountability and non-repudiation for those authorized to define the environment but also enables investigation of changes made by others who may not be authorized.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19198",
+      "title": "Message size restriction is specified at the SMTP connector level. . ",
+      "description": "E-mail system availability depends in part on best practices strategies for setting tuning configurations.   For message size restrictions, multiple places exist to set or override inbound or outbound message size.  Failure to control the configuration strategy can result in loss of data or system availability. \n\nThis setting enables the Administrator to control the maximum size of outgoing messages on an SMTP Connector.  It is recommended that, in general, no limits are applied at the connector level.  This is done so that connectors do not end up prohibiting the delivery of messages that would otherwise be permitted by the Exchange configuration at the virtual server level.  Using connectors to control size limits at an enterprise-wide level is discouraged since the limits would need to be applied to every potential connector in order to create an effective enterprise-wide limit.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-53399",
+      "title": "Exchange Server Software that is no longer supported by the vendor for security updates must not be installed on a system.",
+      "description": "Exchange Server Software that is no longer supported by Microsoft for security updates is not evaluated or updated for vulnerabilities, leaving it open to potential attack. Organizations must transition to a supported Exchange Server Software to ensure continued support.",
+      "severity": "high"
+    }
+  ]
+}