{
  "name": "stig_microsoft_exchange_2010_edge_transport_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 Edge Transport Server Role",
  "version": "1",
  "item_syntax": "^\\w-\\d+$",
  "section_separator": null,
  "items": [
    {
      "id": "Exch-ED-200",
      "title": "SMTP automated banner response must be set.",
      "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": "Exch-ED-201",
      "title": "Receive Connector message size must be controlled.",
      "description": "This setting can be used to limit the total size of messages at the connector level. This includes the message header, the message body, and any attachments. For internal message flow, Exchange Server uses the custom X-MS-Exchange-Organization-OriginalSize: message header to record the original message size of the message as it enters the Exchange Server organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. This setting somewhat limits the impact a malicious user or a computer with malware can have on the Exchange infrastructure by restricting the size of incoming messages.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-202",
      "title": "Receive Connector connections count  must  be controlled.",
      "description": "Email system availability depends in part on best practices strategies for setting tuning. This configuration controls the maximum number of simultaneous inbound connections allowed to the 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.\n",
      "severity": "low"
    },
    {
      "id": "Exch-ED-203",
      "title": "Receive Connector timeout must be limited.",
      "description": "Email system availability depends in part on best practices strategies for setting tuning.   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.   If the timeout period is too long, there is risk that idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established.  \n",
      "severity": "low"
    },
    {
      "id": "Exch-ED-204",
      "title": "Receive Connector must restrict relay access.",
      "description": "This control is used to limit the servers that may use this server as a relay.  If a Simple Mail Transport Protocol (SMTP) sender does not have a direct connection to the Internet (for example, an application that produces reports to be emailed) then it will need to use an SMTP Receive Connector that does have a path to the Internet (for example, a local email server) as a relay.\n\nSMTP relay functions must be protected so 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 Receive Connectors, it is recommended that relays allow only servers that can authenticate.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-205",
      "title": "Internal Receive Connectors must be encrypted.",
      "description": "The Simple Mail Transfer Protocol (SMTP) Receive Connector is used by Exchange 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 Receive Connector.  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, 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, email 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": "Exch-ED-206",
      "title": "Internal Receive Connectors must use Domain Security (Mutual Authentication TLS).",
      "description": "The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the authentication method used for communications between servers.  With this feature enabled, only servers capable of supporting domain authentication will be able to send and receive mail within the domain.\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 server to server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.  \n\nIndividually, channel security and encryption can be compromised by attackers.  Used together, email becomes a more difficult target, and security is heightened.  Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between servers.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-207",
      "title": "Internet Receive Connectors must offer TLS before using basic authentication.",
      "description": "Sending unencrypted email over the Internet increases the risk that messages can be intercepted or altered. Transport Layer Security (TLS) is designed to protect confidentiality and data integrity by encrypting email messages between servers and thereby reducing the risk of eavesdropping, interception, and alteration. This setting forces Exchange to offer TLS before using basic authentication.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-208",
      "title": "Receive Connectors must control the message count per inbound session.",
      "description": "Email 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.  Failure to control message counts as they arrive adds risk that a sending domain could monopolize email resources by not controlling message counts per session as inbound messages arrive. Microsoft best practice recommends setting this to a value of 300.",
      "severity": "low"
    },
    {
      "id": "Exch-ED-209",
      "title": "Receive Connectors must control the number of recipients 'chunked' on a single message.",
      "description": "Email system availability depends in part on best practices strategies for setting tuning configurations. This setting is used when two Exchange servers send or receive email. The chunking setting enables large message bodies to be relayed by the remote server to the Receive Connector in multiple, smaller chunks.",
      "severity": "low"
    },
    {
      "id": "Exch-ED-210",
      "title": "Receive Connectors must be clearly named.",
      "description": "For Receive 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 email 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.\n",
      "severity": "low"
    },
    {
      "id": "Exch-ED-211",
      "title": "Send Connectors must be clearly named.",
      "description": "For Send 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 email 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.\n",
      "severity": "low"
    },
    {
      "id": "Exch-ED-212",
      "title": "Send Connectors delivery retries must be controlled.",
      "description": "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.\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
      "severity": "low"
    },
    {
      "id": "Exch-ED-213",
      "title": "Send Connector message size must be controlled.",
      "description": "This setting can be used to limit the total size of messages at the connector level. This includes the message header, the message body, and any attachments. For internal message flow, Exchange Server uses the custom X-MS-Exchange-Organization-OriginalSize: message header to record the original message size of the message as it enters the Exchange Server organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. This setting somewhat limits the impact a malicious user or a computer with malware can have on the Exchange infrastructure by restricting the size of incoming messages.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-214",
      "title": "Send Connector connections count must be limited.",
      "description": "This setting controls the maximum number of simultaneous outbound connections allowed for a given SMTP Connector, 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.\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.  \n",
      "severity": "low"
    },
    {
      "id": "Exch-ED-215",
      "title": "Send connections per domain must be set.",
      "description": "This configuration controls the maximum number of simultaneous outbound connections to 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 if justified by local site conditions..\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.\n",
      "severity": "low"
    },
    {
      "id": "Exch-ED-216",
      "title": "Internal Send Connectors must use Domain Security (Mutual Authentication TLS).",
      "description": "The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the authentication method used for communications between servers.  With this feature enabled, only servers capable of supporting domain authentication will be able to send and receive mail within the domain.\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 server to server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.  \n\nIndividually, channel security and encryption can be compromised by attackers.  Used together, email becomes a more difficult target, and security is heightened.  Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between servers.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-217",
      "title": "Internal Send Connectors must be encrypted.",
      "description": "The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the encryption method used for communications between servers.  With this feature enabled, only servers capable of supporting Transport Layer Security (TLS) will be able to send and receive mail within the domain.\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 server to server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.  \n\nIndividually, channel security and encryption can be compromised by attackers.  Used together, email becomes a more difficult target, and security is heightened.  Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between servers.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-219",
      "title": "Connectivity logging must be enabled.",
      "description": "A connectivity log is a record of the SMTP connection activity of the outbound message delivery queues to the destination Mailbox server, smart host, or domain. Connectivity logging is available on Hub Transport servers and Edge Transport servers. By default, connectivity logging is disabled. If 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..\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-220",
      "title": "Exchange must not send delivery reports to remote domains.",
      "description": "Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that delivery reports to remote domains are disabled. Before enabling this setting first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-221",
      "title": "Exchange must not send non-delivery reports to remote domains.",
      "description": "Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that non-delivery reports to remote domains are disabled. Before enabling this setting first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-222",
      "title": "External/Internet bound automated response messages must be disabled.",
      "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 if users exist on the server. This can result in the disclosure of active user accounts to third parties, paving the way for possible future attacks.  \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 email recipients.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-223",
      "title": "Auto-forwarding email must be disabled.\n",
      "description": "Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure Automatic Forwards to remote domains are disabled. Before enabling this setting first configure a remote domain.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-224",
      "title": "Exchange must not send auto replies to remote domains.",
      "description": "Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Remote users will not receive automated Out-Of-Office delivery reports. This setting can be used to determine if all the servers in the Organization can send Out-of-Office messages.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-225",
      "title": "Attachment filtering must remove undesirable attachments by file type.",
      "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 are being used more frequently for different forms of attacks. By filtering undesirable attachments a large percent of malicious code can be prevented from entering the system.  Attachments must be controlled at the entry point into the email environment to prevent successful attachment-based attacks. The following is a basic list of known attachments that should be filtered from Internet mail attachments.\n\n*.ade  *.crt  *.jse  *.msi  *.scr  *.wsh  *.dir\n*.adp  *.csh  *.ksh  *.msp  *.sct  *.htm  *.dcr\n*.app  *.exe  *.lnk  *.mst  *.shb  *.html  *.plg\n*.asx  *.fxp  *.mda  *.ops  *.shs  *.htc  *.spl\n*.bas  *.hlp  *.mdb  *.pcd  *.url  *.mht  *.swf\n*.bat  *.hta  *.mde  *.pif  *.vb  *.mhtml  *.zip\n*.chm  *.inf  *.mdt  *.prf  *.vbe  *.shtm  \n*.cmd  *.ins  *.mdw  *.prg  *.vbs  *.shtml  \n*.com  *.isp  *.mdz  *.reg  *.wsc  *.stm  \n*.cpl  *.js  *.msc  *.scf  *.wsf  *.xml  \n",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-227",
      "title": "Non-existent recipients must not be blocked.",
      "description": "SPAM originators, in an effort to refine mailing lists, sometimes use a technique where they first create fictitious names, and then monitor rejected emails 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 email 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.\n",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-228",
      "title": "Tarpitting interval must be set.\n",
      "description": "Tarpitting is the practice of artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of spam or other unwelcome messages. The intent of tarpitting is to slow down the communication process for such email traffic so that the cost of sending spam increases for the person or organization sending the spam. Tarpitting makes directory harvest attacks too costly to automate efficiently.\n\nRecipient Lookup functionality enables the sending server to determine whether an email address is valid or invalid. As mentioned earlier, when the recipient of an inbound message is a known recipient, the Edge Transport server sends back a \"OK\" SMTP response to the sending server. This functionality provides an ideal environment for a directory harvest attack.\n\nA directory harvest attack is an attempt to collect valid email addresses from a particular organization so that the email addresses can be added to a spam database. Because all spam income relies on trying to make people open email messages, addresses known to be active are a commodity that malicious users, or spammers, pay for. Because the SMTP protocol provides feedback for known senders and unknown senders, a spammer can write an automated program that uses common names or dictionary terms to construct email addresses to a specific domain. The program collects all email addresses that return a \"Recipient OK\" SMTP response and discards all email addresses that return a \"User unknown\" SMTP session error. The spammer can then sell the valid email addresses or use them as recipients for unsolicited messages.\n",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-229",
      "title": "Filtered messages must be archived.",
      "description": "As messages are filtered by the Email sanitization process, an archive must be specified and managed by the Email administrators.  The archive may 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. The archive repository may also serve as a base for analysis of filtered content, to report and trend the types of undesirable Email content being captured.  Failure to specify and manage a filtered message archive adds to the risk of email environment pollution.  By not archiving filtered messages it is less likely administrators would be able to analyze and refine the filtering process.  The act of identifying a mailbox causes this feature to be enabled.\n",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-230",
      "title": "Messages with a blank sender field must be filtered.",
      "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 email (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": "Exch-ED-231",
      "title": "Blank sender field action type must be set.",
      "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 email (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": "Exch-ED-232",
      "title": "Accepted domains must be verified.",
      "description": "Exchange may be configured to except email for multiple domain names. This setting controls which domains the server will accept mail. This check verifies the email server is not excepting email for unauthorized domains.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-233",
      "title": "Sender reputation must be enabled.",
      "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.  Sender reputation is anti-spam functionality that blocks messages according to many characteristics of the sender. Sender reputation relies on persisted data about the sender to determine what action, if any, to take on an inbound message. This setting enables the sender reputation function.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-234",
      "title": "Sender reputation must be configured.",
      "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.  Sender reputation is anti-spam functionality that blocks messages according to many characteristics of the sender. Sender reputation relies on persisted data about the sender to determine what action, if any, to take on an inbound message. This setting enables the threshold at which an email will be considered spam.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-236",
      "title": "SPAM evaluation filter must be enabled.",
      "description": "By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages may be eliminated from the transport message stream, preventing their entry into the Exchange environment.  This significantly reduces the attack vector for inbound email-borne SPAM and malware.\nSPAM evaluation (heuristic) filters scan inbound email messages for evidence of SPAM and other attacks that primarily use 'Social Engineering' techniques.  Upon evaluation completion, a rating is assigned to each message estimating the likelihood of its being SPAM.  Upon arrival at the destination mailbox, the junk mail filter threshold (also configurable) determines whether the message will be withheld from delivery, delivered to the junk mail folder, or delivered to the user's inbox.",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-237",
      "title": "Block list service provider must be identified.",
      "description": "Block List filtering is a sanitization process performed on email messages prior to their arrival at the destination mailbox.  By performing this process at the email perimeter, threats can be eliminated outside the enclave, where there is less risk they can do harm.   \n \nBlock List Services (sometimes called Reputation Data Services) are fee based data providers that collect the IP addresses of known Spammers and other malware purveyors.  Block List Service Subscribers benefit from more effective SPAM elimination, which has been estimated as comprising up to 90% of inbound mail volume.  Failure to specify a Block List provider risks that manual email Administration effort would be needed to maintain and update larger block lists than a single email site administrator could conveniently or accurately maintain. \n\nThe 'Block List' Services vendor provides a value for this field usually the DNS suffix for their domain.\n",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-238",
      "title": "Session request from unauthorized senders must be rejected.",
      "description": "Sender Identification (SID) is an email anti-spam sanitization process.  Sender ID uses DNS MX record lookups to verify the SMTP sending server is authorized to send email for the originating domain.\n \nFailure to implement Sender ID risks that SPAM could be admitted into the email domain that originates from rogue servers.  Most SPAM content originates from domains where the IP address has been spoofed prior to sending, thereby avoiding detection.      \n\nBy rejecting session initiations from senders who cannot be validated via Sender ID, potential SPAM is eliminated because it is evaluated prior to being admitted to the domain.   \n",
      "severity": "medium"
    },
    {
      "id": "Exch-ED-239",
      "title": "Sender Identification process must be enabled.",
      "description": "Sender Identification (SID) is an email anti-spam sanitization process.  Sender ID uses DNS MX record lookups to verify the SMTP sending server is authorized to send email for the originating domain.\n \nFailure to implement Sender ID risks that SPAM could be admitted into the email domain that originates from rogue servers.  Most SPAM content originates from domains where the IP address has been spoofed prior to sending, thereby avoiding detection.",
      "severity": "medium"
    }
  ]
}