Skip to main content

How to configure exchange 2007 antispam engine and receive connector to stop spoofing and spams

 Most of organization faces a lot of issue regarding spams and spoofing.

for how we can eliminate the most of spam and spoofing mails is our subject today!.


First of all how we can install the antispam engine onto exchange server, we have to do the following.

Setting up Exchange 2007 anti-spam
Getting Exchange 2007’s anti-spam tools online should be part of your initial set-up process. Once it’s installed you’ll need to open the Exchange Management Shell and run one of the bundled PowerShell scripts. Change directory to c:\Program Files\Microsoft\Exchange Server\Scripts and run install-AntispamAgents.ps1 to enable the Content Filtering tools. Make sure you use the Exchange Management Shell, not the standard PowerShell console, as it loads the appropriate libraries automatically, ready for your scripts to run.

Once you’ve installed the anti-spam agents you’ll need to restart the Exchange transport service. In the Exchange Management Shell type restart-Service MSExchangeTransport to quickly bring the Content Filter online. Switch to the Exchange Management Console, and open the Organization Configuration view. You’ll see a new Anti-spam tab in the Hub Transport section, and this is where you can enable and tune the various spam detection tools used by the Content Filter. The Content Filtering rules are the first port of call, and these let you define what happens to messages that have been identified as spam. You’re able to delete, reject or quarantine messages – delivering quarantined messages to a special mailbox.

Automatically deleting messages that are identified as spam is a risky approach, and we’d recommend just rejecting messages that have the maximum SCL score. This will send an appropriate bounce message, so legitimate senders will be able to tell that their messages are being detected as spam. There’s little need to worry about spammers seeing any bounce messages – the spambots they use won’t have legitimate email addresses. The only person it will inconvenience is anyone whose legitimate email address is used as the reply-to address for spam (a ‘joe job’).

Quarantine
The bigger issue is handling mail that may or may not be spam. That’s where Exchange’s quarantine mailbox comes in. As noted, you need some workarounds to manage it effectively. First you need to create a Quarantine mailbox account, by creating a new Active Directory user (‘quarantine’ is a good name) and giving them a mailbox. If you’re working with a large number of users, Microsoft recommends creating a separate mailbox database for this user. With the mailbox and user in place you can then using the Content Filtering dialog box in the Anti-spam tab to set a SCL for automatically quarantining messages, giving it the fully qualified SMTP email address for the quarantine mailbox.

The default anti-spam tools in Exchange 2007 are effective enough to allow you to set a quarantine SCL score of 6, leaving Outlook’s junk email filter to handle anything that gets through. Once messages have been filtered you can use Outlook or Outlook Web Access to manage the quarantine folder. Setting up multiple Outlook profiles to handle the quarantine user and mailbox isn’t particularly easy – and it’s not really practical when you’re working with several clients. Instead, just log on with Outlook Web Access using the quarantine user’s password, and you’ll be able to triage the quarantine mailbox, using the Send Again function in OWA to send falsely-identified messages to their correct destination (as long as you’re using Internet Explorer). Regular false positives can be whitelisted using some PowerShell to add domains to a list of addresses that will always be accepted.

$domains=get-ContentFilterConfig
$domains.BypassedSenderDomains +=”*.whitelistdomain.com”
$domains| set-ContentFilterConfig


You can improve on the tools used to identify spam messages by subscribing to a real-time block list "RBLs" inside Exchange 2007. Set the IP Block List Providers properties with the DNS details of the RBL you plan to use. One of the best is Spamhaus’ blended list which includes known spam domains as well as the IP addresses of PCs that are currently sending spam. Use zen.spamhaus.org to subscribe your clients’ Exchange servers to this list. There are other properties you can set to manage the SCL rules used by Exchange – including identifying messages sent through open proxies, messages with SenderID set, messages with blank sender fields in their headers, and senders who are also sending messages to non-existent users at a site. One interesting option is the ability to use a whitelisting service, which provides a list of DNS addresses of sites known not to send spam. You need to keep your clients’ content filters up to date to get the most from Exchange’s built-in anti-spam tools. Updates are published at least weekly, so make sure to regularly check Windows Update on your clients’ servers to install any pending filter updates; you don’t even have to reboot Exchange to get the updates.


How to configure Antispam engine.


Configuring Connection Filtering


Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
This topic provides an overview of how to configure connection filtering. For customized or more advanced configuration, see the links in each section of this topic. For more information about how connection filtering works, see Connection Filtering.



Note: From the perspective of configurable components on a computer that has the Edge Transport server role installed, the connection filtering feature refers to a collection of IP Block lists, IP Allow lists, IP Block List providers, and IP Allow List providers. Connection filtering is used to extend the server.
When you configure connection filtering, you must follow these steps:

  1. Enable connection filtering components.
  2. Add IP addresses to the IP Allow lists and IP Block lists.
  3. Configure IP Allow List providers and IP Block List providers.
  4. Configure connection filtering for Edge Transport servers that are not the first Simple Mail Transfer Protocol (SMTP) entry point.
  5. Test IP Block and IP Allow functionality.

Important: Configuration changes that you make to connection filtering by using the Exchange Management Console or the Exchange Management Shell are made only to the local computer that has the Edge Transport server role installed. If you have multiple instances of the Edge Transport server role running in your organization, you must apply connection filtering configuration changes to each computer.
 Enabling Connection Filtering Components
By default, connection filtering is enabled on the Edge Transport server for inbound messages that come from the Internet but are not authenticated. These messages are handled as external messages. You can disable the filter in individual computer configurations by using the Exchange Management Console or the Exchange Management Shell.
When connection filtering is enabled on a computer, the Connection Filter agent filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources. These are considered anonymous Internet sources.
For more information about how to configure Receive connectors and how message source categories are determined, see Receive Connectors.
As a best practice, you should not filter messages from trusted partners or from inside your organization. When you run anti-spam filters, there is always a chance that the filters will detect false positives. To reduce the chance of mishandling legitimate e-mail messages, you should enable anti-spam agents to run only on messages from potentially untrusted and unknown sources. You can enable and disable connection filtering on messages from any source by using the Exchange Management Shell.
For more information about how to enable connection filtering, see How to Enable Connection Filtering.



 Adding IP Addresses to the Block and Allow Lists
As explained in Connection Filtering, IP Block lists and IP Allow lists are administrator-defined lists that specify IP addresses and IP address ranges that are acted on by connection filtering. If an originating IP address matches an IP address or IP address range on the IP Block list, the Connection Filter agent processes all RCPT TO: headers in the message and then denies the message after the MAIL FROM command. When an originating IP address matches an IP address or IP address range on the IP Allow list, the Connection Filter agent sends the message to the destination without additional processing by other anti-spam agents. For more information about how the anti-spam agents work together and the order in which they are applied, see Anti-Spam and Antivirus Functionality.
Note: The use of Internet Protocol Version 6 (IPv6) addresses and IP address ranges is supported only when Microsoft Exchange Server 2007 Service Pack 1 (SP1) is deployed on a computer that is running Windows Server 2008, both IPv6 and Internet Protocol Version 4 (IPv4) are enabled on that computer, and the network supports both IP address versions. If Exchange 2007 SP1 is deployed in this configuration, all server roles can send data to and receive data from devices, servers, and clients that use IPv6 addresses. A default installation of Windows Server 2008 enables support for IPv4 and IPv6. If Exchange 2007 SP1 is installed on Windows Server 2003, IPv6 addresses are not supported. For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.
For more information about how to add IP addresses to the IP Block list and IP Allow list, see How to Add IP Addresses to the IP Allow List and IP Block List.



 Configuring IP Block List Providers and IP Allow List Providers
IP Block list and IP Allow list provider services can help you reduce spam and increase overall message processing on your Edge Transport server. You should consider configuring multiple IP Block List provider services and IP Allow List provider services.



Note: Multiple IP Block List provider services are sometimes referred to as real-time block list (RBL) services. IP Allow List provider services are sometimes referred to as safe list services.
For each IP Block List provider service that you configure, you can customize the SMTP 550 error that is returned to the sender when the sender IP address is matched to an IP Block List provider service and is subsequently blocked by the Connection Filter agent. It is a best practice to customize the SMTP 550 error to identify the IP Block List provider service that identifies the sender as a blocked IP address. This best practice enables legitimate senders to contact the IP Block List provider service so that they can be removed from the IP Block List provider service's IP Block list.
Different IP Block List provider services may return different codes when the IP address of a remote server that is sending a message matches an IP address on an IP Block List provider service's IP Block list. Most IP Block List provider services return one of the following data types: bitmask or absolute value. Within these data types, there may be multiple values that indicate the type of list that the submitted IP address is on.
 Bitmask Example
This section shows an example of the status codes returned by most Block List providers. See the documentation from the specific provider on the status codes that the provider returns.
For bitmask data types, the IP Block List provider service returns a status code of 127.0.0.x, where the integer x is any one of the values that are listed in the following table.
Values and status codes for bitmask data types

Value Status Code 1
The IP address is on an IP Block list.
2
The SMTP server is configured to act as an open relay.
4
The IP address supports a dial-up IP address.
For absolute value types, the IP Block List provider service returns explicit responses based on the cause of the block of the IP address. The following table shows some examples of absolute values and the explicit responses.
Values and status codes for absolute value data types

Value Explicit Response 127.0.0.2
The IP address is a direct spam source.
127.0.0.4
The IP address is a bulk mailer.
127.0.0.5
The remote server that is sending the message is known to support multistage open relays.
For more information about how to configure IP Allow List providers and IP Block List providers, see How to Configure IP Allow List and IP Block List Providers.


Configuring Connection Filtering for Edge Transport Servers That Are Not the First SMTP Entry Point
In some organizations, the Edge Transport server role is installed on computers that do not process SMTP requests directly on the Internet. In this scenario, the Edge Transport server is behind another front-end SMTP server that processes inbound messages directly from the Internet. In this scenario, the Connection Filter agent must be able to extract the correct originating IP address from the message. To extract and evaluate the originating IP address, the Connection Filter agent must parse the Received headers from the message and compare those headers to the known SMTP server in the perimeter network.
When an RFC-compliant SMTP server receives a message, the server updates the message's Received header with the domain name and IP address of the sender. Therefore, for each SMTP server that is between the originating sender and the Edge Transport server, the SMTP server adds an additional Received header entry.
When you configure your perimeter network to support Microsoft Exchange Server 2007, you must specify all the IP addresses for the SMTP servers in your perimeter network. The IP address data is replicated to Edge Transport servers by EdgeSync. When messages are received by the computer that runs the Connection Filter agent, the IP address in the Received header that does not match an SMTP server IP address in your perimeter network is assumed to be the originating IP address.
You must specify all internal SMTP servers on the transport configuration object in the Active Directory forest before you run connection filtering. Specify the internal SMTP servers by using the InternalSMTPServers parameter on the Set-TransportConfig cmdlet.


Testing IP Block List and IP Allow List Functionality
After you configure an IP Block List provider service or IP Allow List provider service, you can test to make sure that connection filtering is configured correctly for the particular service. Most IP Block List provider services or IP Allow List provider services provide test IP addresses that you can use to test their services. When you run a test against an IP Block List provider service or an IP Allow List provider service, the Connection Filter agent issues a Domain Name System (DNS) query that is based on the real-time block list (RBL) IP address that should respond with a specific response. For more information about RBL services, see Connection Filtering. For more information about how to test IP addresses against an IP Block List provider service or an IP Allow List provider service, see Test-IPAllowListProvider and Test-IPBlockListProvider.


Configuring Content Filtering





Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
This topic explains how to use the Exchange Management Console or the Exchange Management Shell to configure the Content Filter agent in Microsoft Exchange Server 2007. This topic also provides an introduction to configuration of the Content Filter agent. For more information about customized or advanced configuration, see the links in each section of this topic. For more information about how the Content Filter agent works, see Content Filtering.
To configure the Content Filter agent, you must follow these steps:

  1. Enable the Content Filter agent.
  2. Specify a spam quarantine mailbox.
  3. Enable and configure the spam confidence level (SCL) thresholds and SCL threshold actions. These actions include deleting messages, rejecting messages, or quarantining messages.
  4. Enable or disable puzzle validation.
  5. Specify recipient and sender exceptions.
  6. Configure Allow phrases and Block phrases.
  7. Set the rejection response.

Important: Configuration changes that you make to the Content Filter agent by using the Exchange Management Console or the Exchange Management Shell are made only to the local computer that has the Edge Transport server role installed. If you have multiple instances of the Edge Transport server role running in your organization, you must configure the Content Filter agent on each computer.

Note: Safelist aggregation is performed by the Content Filter agent. Safelist aggregation is likely the most effective way to reduce false positives. As its name suggests, this functionality collects data from the anti-spam safe lists that Microsoft Office Outlook and Outlook Web Access users configure and makes this data available to the anti-spam agents on the Edge Transport server in Exchange Server 2007. Although the Content Filter agent acts on the safelist aggregation configuration, you do not administer or configure safelist aggregation directly through the Content Filter agent. However, the Content Filter agent must be enabled for safelist aggregation to function. For more information, see How to Configure Safelist Aggregation.
 Enabling the Content Filter Agent
When the Content Filter agent is enabled on a computer, the Content Filter agent filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources that are considered anonymous Internet sources.
For more information about how to configure Receive connectors and how message source categories are determined, see Receive Connectors.
As a best practice, you should not filter messages from trusted partners or from inside your organization. When you run anti-spam filters, there is always a chance that the filters will detect false positives. To reduce the chance of mishandling legitimate e-mail messages, you should enable anti-spam agents to run only on messages from potentially untrusted and unknown sources.
For more information about how to enable or disable content filtering, see How to Enable or Disable Content Filtering.



 Specifying a Spam Quarantine Mailbox
If you decide to enable the quarantine SCL threshold that is discussed in the next section, you must first configure the spam quarantine infrastructure. All messages that equal to or greater than the Spam Quarantine SCL threshold are sent to the SMTP address that you specify in this step. For more information, see Configuring and Managing Spam Quarantine.
After you set up the spam quarantine mailbox and infrastructure, you must specify the mailbox in the content filter configuration. The QuarantineMailbox parameter takes the Simple Mail Transfer Protocol (SMTP) address of the spam quarantine mailbox.
For more information about how to specify the spam quarantine mailbox, see How to Specify a Spam Quarantine Mailbox.
Important: By the nature of the spam quarantine feature, the IT administrator who is responsible for the spam quarantine mailbox can view potentially private and sensitive messages and send mail on behalf of anyone in the Exchange organization.


 Enabling and Configuring the SCL Threshold
As explained in Content Filtering, the SCL threshold is the value at which a particular message is identified as potential spam and is acted on. If you have enabled and configured all default anti-spam agents, the Content Filter agent is the last filter to scan incoming messages. Therefore, the settings of the SCL thresholds and threshold actions are very important. If you set the SCL thresholds too high, you may not reduce the spam that enters your organization. If you set the SCL thresholds too low, you risk filtering messages that come from legitimate users. For more information about how to plan an anti-spam strategy and how to optimize settings for the anti-spam agents, see Anti-Spam and Antivirus Functionality.
Note: After you configure the SCL thresholds, you should periodically monitor these settings and adjust them according to your organization's needs.
You configure the Content Filter agent to act on messages according to their SCL rating. For example, you may determine that messages that have an SCL rating of 7 or greater must be deleted, whereas messages that have an SCL rating of 6 are rejected, and messages that have an SCL of 5 are quarantined. You can configure the Content Filter agent to take the following actions when a message exceeds different SCL ratings:

  • Deletes message
  • Rejects message
  • Quarantines message

You can adjust the SCL threshold behavior by assigning different SCL ratings to each of these actions. You can set each SCL threshold action to a value between 0 and 9, where 0 is considered less likely to be spam, and 9 is considered more likely to be spam.
For more information about how to adjust the SCL threshold to suit your organization's requirements and how to adjust per-recipient SCL thresholds, see the following topics:



 Enabling and Disabling Outlook E-mail Postmark Validation
Outlook E-mail Postmark validation is a computational proof that Outlook applies to outgoing messages to help recipient messaging systems distinguish legitimate e-mail from junk e-mail. This feature helps reduce the chance of false positives. In the context of spam filtering, a false positive exists when a spam filter incorrectly identifies a message from a legitimate sender as spam. When Outlook E-mail Postmark validation is enabled, the Content Filter agent parses the inbound message for a computational postmark header. The presence of a valid, solved computational postmark header in the message indicates that the client computer that generated the message solved the computational postmark. The results of the postmark validation are calculated into the overall SCL for the incoming message. If the postmark validation feature is enabled and an inbound message either does not contain a computational postmark header or the computational postmark header is not valid, the Content Filter agent would not change the SCL rating.
By default, postmark validation is enabled. For more information about how to enable postmark validation, see How to Enable or Disable Outlook E-Mail Postmark Validation.



 Specifying Recipient and Sender Exceptions
Sometimes, you may not want messages that are intended for specific recipients to be filtered by the Content Filter agent. For example, if you have a customer support e-mail alias, you may want to accept all incoming e-mail messages for that address. In this case, you can specify recipients in your organization for which messages are not filtered by the Content Filter agent.
You can also specify senders and sender domains that you do not want to be filtered by the Content Filter agent. Bypassing content filtering for specific senders and sender domain messages is useful if there are external entities that your organization frequently exchanges messages with. Frequently, business contacts in this category may be excluded from content filtering by using individual Office Outlook 2003 users' Safe Senders Lists in your organization. For more information about how to specify recipient and sender exceptions, see How to Specify Recipient and Sender Exceptions for Content Filtering.



 Specifying Allow Phrases and Block Phrases
As explained in Content Filtering, you can configure the Content Filter agent to recognize and filter on certain phrases. You must specify words or phrases for the Content Filter to act on. When you specify a word or phrase, you must specify whether it is an Allow phrase or a Block phrase. When the Content Filter agent encounters an Allow phrase in a message, the SCL is set to 0. When the Content Filter agent encounters a Block phrase in a message, the SCL is set to 9.
For more information about how to specify allow and block words or phrases, see How to Configure Allow or Block Phrases for Content Filtering.



 Setting the Rejection Response
When the SCL reject threshold is exceeded, the Content Filter agent does not accept the message and instead sends a rejection response during the SMTP transaction. The rejection response is an SMTP response from the Edge Transport server to the sending server.
The SCL Reject action must be enabled for the rejection response to be sent. If you enable the SCL reject action and do not change the value of the rejection response, the default rejection response, "Message rejected due to content restrictions," will be sent.

Configuring Recipient Filtering



Yahoo.com and hotmail.com are just an examples. if you can have a lot of accepted domains so you may use multiple domains to block some users from receiving mails, If you have only one domain like EgyEng.com so you may need to block one user from receiving mails.

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
This topic explains how to use the Exchange Management Console or the Exchange Management Shell to configure the Recipient Filter agent. This topic also provides an overview of how to configure the Recipient Filter agent. For basic configuration, see the procedures in this topic. For more customized or advanced configuration, see the links in each section of this topic. For more information about how the Recipient Filter agent works, see Recipient Filtering.
When you configure the Recipient Filter agent, you must follow these steps:

  1. Enable the Recipient Filter agent.
  2. Add recipients to the Recipient Block list.
  3. Configure Active Directory Application Mode (ADAM) for recipient lookup.
  4. Configure the tarpitting interval.

As a best practice, you should not filter messages from trusted partners or from inside your organization. When you run anti-spam filters, there is always a chance that the filters will detect false positives. To reduce the chance of mishandling legitimate messages, you should enable anti-spam agents to run only on messages from potentially untrusted and unknown sources.
Important: Configuration changes that you make to the Recipient Filter agent by using the Exchange Management Console or the Exchange Management Shell are only made to the local computer that has the Edge Transport server role installed. If you have multiple instances of the Edge Transport server role running in your organization, you must make Recipient Filter configuration changes to each computer.
 Enabling the Recipient Filter Agent
By default, recipient filtering is enabled on the computer that has the Microsoft Exchange Server 2007 Edge Transport server role installed for inbound messages that come from the Internet but are not authenticated. These messages are handled as external messages. You can disable the Recipient Filter agent in individual computer configurations by using the Exchange Management Console or the Exchange Management Shell.
When the Recipient Filter agent is enabled on a computer, the Recipient Filter agent filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources, which are considered anonymous Internet sources.
For more information about how to enable the Recipient Filter agent, see How to Enable Recipient Filtering.



 Adding Recipients to the Recipient Block List
As explained in Recipient Filtering, you can configure recipient filtering to block inbound messages for specific recipients in your organization. If an inbound message contains a recipient that is on the Recipient Block list, the Edge Transport server sends a "550 5.1.1 User unknown" Simple Mail Transfer Protocol (SMTP) session error to the sending system.
By default, recipient blocking is not enabled. After you add recipients to the Recipient Block list, you must enable recipient blocking.
For more information about how to add recipients to the Recipient Block list, see How to Add Recipients to the Recipient Block List.



 Configuring ADAM for Recipient Lookup
One of the most effective ways to reduce spam is to validate recipients before accepting inbound messages from the Internet. Therefore, it is a good idea to configure the ADAM instance that runs on the Edge Transport server to synchronize with your Active Directory directory service. By default, ADAM is installed and configured on the Edge Transport server. However, you must configure ADAM to communicate with an Active Directory domain-joined global catalog server. Most of the time, you must also configure your firewall to enable specific ports to communicate with ADAM. For more information, see Subscribing the Edge Transport Server to the Exchange Organization.
After you configure ADAM to replicate a Recipient Block list from Active Directory, you must then enable blocking of messages that are sent to recipients who are not present in the Exchange organization. You enable message blocking on the Blocked Recipients tab of the Recipient Filtering Properties page in the Exchange Management Console. You can also enable message blocking by using the Set-RecipientFilterConfig command in the Exchange Management Shell. For more information, see Set-RecipientFilterConfig.



 Configuring the Tarpitting Interval
As explained in Recipient Filtering, you can configure the Receive connectors that process inbound messages from the Internet to slow down the SMTP response. Make sure that you enable tarpitting functionality on the Receive connectors, especially if you have enabled the Recipient Lookup feature of recipient filtering. If you do not enable tarpitting, and you have enabled the Recipient Lookup feature, you are exposing your organization to a directory harvest attack. A directory harvest attack will likely cause more spam.
When you specify a tarpitting interval time on a Receive connector, tarpitting is enabled. The default value is 5 seconds. We recommend that you start with a value of 5 (seconds). Use caution if you decide to change this value. An overly long interval could disrupt ordinary mail flow, whereas an overly brief interval may not be as effective in thwarting a directory harvest attack. If you change the tarpitting interval value, do so in small increments.
You set the tarpitting interval on the Security tab of the Receive connector property pages in the Exchange Management Console. For more information about how to use the Exchange Management Console to configure the tarpitting interval, see How to Modify the Configuration of a Receive Connector.
You can also set the tarpitting interval by using the Set-ReceiveConnector command in the Exchange Management Shell.





Configuring Sender Filtering





Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
This topic explains how to use the Exchange Management Console or the Exchange Management Shell to configure the Sender Filter agent. This topic also provides an overview of how to configure the Sender Filter agent. For basic configuration, see the procedures in this topic. For more information about how the Sender Filter agent works, see Sender Filtering.
When you configure the Sender Filter agent, you must follow these steps:

  1. Enable the Sender Filter agent.
  2. Add blocked senders and domains.
  3. Enable blank sender blocking.
  4. Specify the blocking action.

Important: Configuration changes that you make to the Sender Filter agent by using the Exchange Management Console or the Exchange Management Shell are made only to the local computer that has the Edge Transport server role installed. If multiple instances of the Edge Transport server role are running in your organization, you must apply sender reputation configuration changes to each computer.
 Using the Sender Filter Agent to Block Messages
By default, sender filtering is enabled on the computer that has the Edge Transport server role installed for inbound messages that come from the Internet but are not authenticated. These messages are handled as external messages. You can disable the Sender Filter agent in individual computer configurations by using the Exchange Management Console or the Exchange Management Shell.
When you enable the Sender Filter agent on a computer, the Sender Filter agent filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources. These are considered anonymous Internet sources.
For more information about how to configure Receive connectors and how message source categories are determined, see Receive Connectors.
As a best practice, you should not filter e-mail messages from trusted partners or from inside your organization. When you run anti-spam filters, there is always a chance that the filters will detect false positives. You should enable anti-spam agents to run only on messages from potentially untrusted and unknown sources. This will reduce the chance that anti-spam filters will mishandle legitimate messages. You can enable and disable the Sender Filter agent to run on messages from any source by using the Exchange Management Shell. For more information, see Set-SenderFilterConfig.
You can configure the Sender Filter agent to block inbound messages that do not specify a sender and domain in the MAIL: FROM SMTP header. You can use this feature to prevent non-delivery report (NDR) attacks on the Exchange server. Most legitimate SMTP messages come from SMTP servers that provide a sender and domain in the MAIL FROM SMTP command.



 Specifying the Block Action
After you have specified blocked senders and domains, you must specify how you want the Sender Filter agent to act on messages from blocked senders and domains. We recommend that you reject the messages. When you use the Sender Filter agent, on which all blocked e-mail addresses and domains are specified by the Edge Transport server administrator, the chance of false positives is relatively less than when you use other anti-spam agents. For example, the Content Filter agent is an anti-spam agent that relies on many different variables to determine whether a message is spam.
There are only two scenarios in which legitimate messages may be rejected by the Sender Filter agent:

  • If you mistype an e-mail address or domain name, the wrong sender may be blocked.
  • If a domain name is reregistered to a legitimate company after you add the domain to your Blocked Senders list, you will unintentionally block legitimate messages.

In either of these cases, it may still make sense to reject the messages.


Configuring Sender ID






Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
This topic explains how to use the Exchange Management Console or the Exchange Management Shell to configure Sender ID in Microsoft Exchange Server 2007. The Sender ID agent is an anti-spam agent that is enabled on computers that have the Edge Transport server role installed. Sender ID tries to verify that every e-mail message originates from the Internet domain from which it claims to have been sent. Sender ID checks the address of the server that sends the message against a registered list of servers that the domain owner has authorized to send e-mail.
For more information about how Sender ID works, see Sender ID and the Microsoft.com topic about Sender ID.
To use Sender ID to filter spam, follow these steps:

  1. Update your organization's Internet-facing domain name system (DNS) to support Sender ID.
  2. Enable Sender ID on the Edge Transport server.
  3. Specify recipients and sender domains that you want to exclude from Sender ID filtering.
  4. Configure the actions that Sender ID takes on specific types of status information.

Important: Changes that you make to the Sender ID configuration by using the Exchange Management Console or the Exchange Management Shell are made only to the local computer that has the Edge Transport server role installed. If you have multiple instances of the Edge Transport server role running in your organization, you must apply Sender ID configuration changes to each computer.
 Updating Your Organization's Internet-Facing DNS to Support Sender ID
The effectiveness of Sender ID depends on specific DNS data. The more organizations that update their Internet-facing DNS servers by using a sender policy framework (SPF) record, the more effectively Sender ID identifies spoofed e-mail messages. For more information about how Sender ID uses DNS data to identify spoofed messages, see Sender ID.
To support the Sender ID infrastructure, you must update your Internet-facing DNS data by creating an SPF record and hosting the SPF record on your public DNS servers. For more information about how to create and deploy SPF records, see the Microsoft.com topic, Sender ID.



 Enabling Sender ID
By default, Sender ID is enabled on the Edge Transport server role for inbound messages that come from the Internet but are not authenticated. These messages are handled as external messages. You can disable Sender ID in individual computer configurations by using the Exchange Management Console or the Exchange Management Shell.
When Sender ID is enabled on a computer, it filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources. These are considered anonymous Internet sources.
For more information about how to configure Receive connectors and how message source categories are determined, see Receive Connectors.
As a best practice, you should not filter messages from inside your organization or from trusted partners. When you run anti-spam filters, there is always a chance that the filters will detect false positives. To reduce the chance of mishandling legitimate e-mail messages, you should enable anti-spam agents to run only on messages from potentially untrusted and unknown sources. You can enable and disable Sender ID to run on messages from any source by using the Exchange Management Shell.
For more information about how to enable or disable Sender ID, see How to Enable Sender ID.



 Specifying Recipients and Sender Domains to Exclude From Sender ID Filtering
You may want to exclude specific recipients and sender domains from Sender ID filtering. To do this, specify the recipients and sender domains in the Exchange Management Shell. You cannot specify the recipients and sender domains in the Exchange Management Console.
For more information about how to set recipient and sender domain exclusions for Sender ID, see Set-SenderIdConfig.



 Configuring Sender ID Actions
As described in Sender ID, the Sender ID evaluation process generates a Sender ID status when the agent detects messages that are spoofed or have a transient error. You can set a separate Sender ID action for instances when a message is spoofed and for instances when a transient error is returned:

  • To set an action for instances when a message is spoofed, you can use the Exchange Management Console or the Exchange Management Shell.
  • To set an action for instances when a transient error is returned, you must use the Set-SenderIdConfig command in the Exchange Management Shell. You cannot set the action in the Exchange Management Console.

You can configure the Sender ID agent to perform one of the following actions:

  • Stamp the message with the status.
  • Reject the e-mail and send an SMTP error response to the sending server.
  • Delete the message without sending a response.

The default for both instances is to stamp the message with the Sender ID result and continue to process the message.
For detailed instructions on how to configure Sender ID actions, see How to Configure Sender ID Actions.

Comments

Popular posts from this blog

ما هى ال FSMO Roles

  بأختصار ال FSMO Roles هى اختصار ل Flexible Single Operation Master و هى عباره عن 5 Roles فى ال Active Directory و هما بينقسموا لقسمين A - Forest Roles 1- Schema Master Role و هى ال Role اللى بتتحكم فى ال schema و بيكون فى Schema Master Role واحد فى ال Forest بيكون موجود على Domain Controller و بيتم التحكم فيها من خلال ال Active Directory Schema Snap in in MMC بس بعد ما يتعمل Schema Register بواسطه الامر التالى من ال Cmd regsvr32 schmmgmt.dll 2-Domin Naming Master و هى ال Role المسئوله عن تسميه ال Domains و بتتأكد ان مفيش 2 Domain ليهم نفس الاسم فى ال Forest و بيتم التحكم فيها من خلال ال Active Directory Domains & Trusts B- Domain Roles 1-PDC Emulator و هى ال Role اللى بتتحكم فى ال Password change فى ال domain و بتتحكم فى ال time synchronization و هى تعتبر المكان الافتراضى لل GPO's و هى تعتبر Domain Role مش زى الاتنين الاولانيين و بيتم التحكم فيها من خلال ال Active directory Users & Computers عن طريق عمل كليك يمين على اسم الدومين و نختار operations master فى تاب ال PDC Emu

Recreating a missing VMFS datastore partition in VMware vSphere 5.x and 6.x

    Symptoms A datastore has become inaccessible. A VMFS partition table is missing.   Purpose The partition table is required only during a rescan. This means that the datastore may become inaccessible on a host during a rescan if the VMFS partition was deleted after the last rescan. The partition table is physically located on the LUN, so all vSphere hosts that have access to this LUN can see the change has taken place. However, only the hosts that do a rescan will be affected.   This article provides information on: Determining whether this is the same problem Resolving the problem   Cause This issue occurs because the VMFS partition can be deleted by deleting the datastore from the vSphere Client. This is prevented by the software, if the datastore is in use. It can also happen if a physical server has access to the LUN on the SAN and does an install, for example.   Resolution To resolve this issue: Run the  partedUtil  command on the host with the issues and verify if your output

Unlock the VMware VM vmdk file

  Unlock the VMware VM vmdk file Kill -9 PID Sometimes a file or set of files in a VMFS become locked and any attempts to edit them or delete will give a device or resource busy error, even though the vm associated with the files is not running. If the vm is running then you would need to stop the vm to manipulate the files. If you know that the vm is stopped then you need to find the ESX server that has the files locked and then stop the process that is locking the file(s). 1. Logon to the ESX host where the VM was last known to be running. 2.  vmkfstools -D /vmfs/volumes/path/to/file  to dump information on the file into /var/log/vmkernel 3.  less /var/log/vmkernel  and scroll to the bottom, you will see output like below: a. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)FS3: 130: <START vmware-16.log> b. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)Lock [type 10c00001 offset 30439424 v 21, hb offset 4154368 c. Nov 29 15:49:17 vm22 vmkernel: gen 664