Agari’s Sensor is designed to gather metadata from enterprise email traffic to aid analysis and increase visibility. The Sensor is designed to be compatible with Proofpoint-based email ingress and receiving infrastructure.

Establishing dual delivery, where messages destined to the organization’s end-user mailboxes are simultaneously copied to one or more Agari Sensors, provides the Sensor with access to email streams. Doing so requires a few simple configuration changes on the Proofpoint instances. These changes can be made directly in the Proofpoint administrative user interface. This document describes how to make the necessary changes quickly and safely. These instructions apply to Proofpoint versions 7.x through 8.0.1, and will possibly be applicable to more recent versions.

For more information on the general architecture of the Sensor, installation requirements, expected performance, monitoring, and testing see the Deployment Requirements and Installation Guide documents.

High-level Summary:

Create an SMTP sending Profile that specifies a route for email to the Agari Sensor.
Create a Spam Detection Rule that directs Proofpoint to send a copy of non-spam messages using the SMTP Profile.
Enable SPF detection.
Configure TLS Encryption, if desired.
Confirm that any desired system Alerts are in place to inform administrators of any problems.
Consider other whitelisted email streams.
Whitelist Agari’s alerts server to ensure that you and your users receive alerts.

Important consideration regarding the “Authentication-Results” header:

Agari depends on the presence of an accurate, uncorrupted Authentication-Results header to do its job. Typically, the perimeter MTA for your institution (meaning, the first point of entry into your institution from the foreign MTAs on the internet) will evaluate the incoming messages and add an Authentication-Results header, and any downstream MTAs in your institution will be carefully configured to preserve the integrity of this header (e.g. they must not overwrite it with their own header unless they are able to do so with accurate information, and they must not strip the header from the message.).

However, mail environments can be complex, and it’s not always practical to ensure the integrity of the header for every downstream MTA. To simplify the situation, Agari’s Sensors will first look for a duplicate of the header called X-Agari-Authentication-Results. If they find none, they will fall back to the Authentication-Results header.

This allows you to configure your perimeter MTA to create (or duplicate) the Authentication-Results header under an alternate name: it will stand a greater chance of making it through your various downstream MTAs without being corrupted. Agari provides instructions on how to do this for various MTA products.

If you have been pointed here for those specific instructions, you will find them at the end of this document.

If, instead, you are configuring your MTA for Dual-Delivery, please begin here:

Create an SMTP Profile

The first step is to create an SMTP sending profile that will be used for sending the duplicate message stream. Open the System > Settings > SMTP page in the configuration UI:

Click Add Profile to create a new SMTP profile. The exact details to use in this profile will vary depending on your infrastructure.

The ID of the profile is your choice, we suggest agari. For the Description, use something instructive like SMTP profile to send to Agari sensor. The Host should be set to the IP address or hostname assigned to an instance of the Agari Sensor. If you are using multiple Sensors, you can specify multiple hosts/IPs here, separated by a comma, but without any spaces on the line.

Example “123.123.45.67,123.123.45.67,backup-sensor.otherdomain.com”.

Delivery Type can be left at the default of Load Balanced or, if you have multiple Sensors and would prefer that the first listed be used as the main Sensor and subsequent to be used in case of failure, Ordered.

Port should be left at 25 (exception: if you know your Sensor has been pre-configured to listen on a port other than 25), and Timeout can be left blank or configured as you see fit: you may want to set a relatively quick timeout so that in the event of a loss of connectivity to the Sensor, your Proofpoint system does not spend much time attempting to deliver.

The From Address can be set to something like “proofpoint-pps@yourdomain.com” it’s not actually relevant in this application. HELO domain is also not important and can be set to the mail domain of your company, e.g. “yourdomain.com”. SMTP Address should remain at Use Original-Recipient Address.

The Login/Password fields can be left blank (they will be populated with asterisks if you edit the SMTP profile later you can ignore them.) Your SMTP profile might look something like this:

You can click Test SMTP Connection to ensure connectivity to the Sensor, or simply click Save Changes and wait for your Proofpoint system to update.

Create a Spam Detection Rule

Now you will create a Spam Detection Rule to tell Proofpoint to send a copy of all messages to the Agari Sensor, using the SMTP Profile you previously created. Note that in order for this to work, Spam Detection must be enabled at Spam Detection > Settings. (If you are not using Spam Detection in Proofpoint, and would prefer not to, you can use an Email Firewall Rule instead, see the end of this section.)

Go to the Spam Detection > Policies > Rules page:

The last rule in the list is the Not Spam rule. Find this rule and click Edit to edit that rule

(On the edit screen, the rule will probably already have a checked box at Change message headers to add an “X-Proofpoint-Spam-Details” header. You can leave this unchanged. If you have disabled it already, that’s also fine: the Agari Sensor will be indifferent to this setting.)

Important: this next step, relating to the X-Agari-Authentication-Results header, should only be performed if your Proofpoint MTA is a perimeter MTA. If, instead, your Proofpoint MTA is downstream from a perimeter MTA, then the information added with this header is likely to be incorrect, and creating the header would corrupt the information you see in the Enterprise Protect dashboard in that case, simply skip this section and continue where the instructions read “That concludes the section of instructions for perimeter MTAs only”.

If your Proofpoint MTA is a perimeter MTA, then you need to edit the rule to add an X-Agari-Authentication-Results header to Not Spam messages. Note that you must enable SPF evaluation in your Proofpoint system for this to work that will be discussed in a following section.

Underneath Change message header, click Add to bring up the Change Header dialog. Leave the Operation set to Add header. For Header Name, enter the string “X-Agari-Authentication-Results”, being careful to type it in exactly as shown, with no trailing colon. For the Value, enter the following string (copy and paste may be advisable), also being careful not to make any type mistakes or alterations whatsoever, except to change “mx.yourdomain.com” (as explained in the following paragraph):

mx.yourdomain.com; spf=${SPFResult} smtp.mailfrom=${OriginalSender} smtp.helo=${Helo}

“mx.yourdomain.com” can be chosen by you to represent the authenticating authority. If your company is “yourdomain.com”, you might choose “mx.yourdomain.com” or “proofpoint.yourdomain.com” or some similar identification to represent the mail system doing the authentication. For more information about choosing this value, see RFC 5451, section 2.3.

Your Change Header dialog will look something like below (note that the Value field is truncated in this image):

Click Save Changes.

That concludes the section of instructions for perimeter MTAs only.

The follow instructions are to be performed in all cases:

Returning now to the Not Spam rule edit screen, check Send a copy to destination. Select Copy filtered message. In the drop-down menu, select the SMTP Profile that you recently created (“agari”, in our example.)

Unless you have good reason to, do not change the Delivery Method from Continue or you risk stopping incoming mail for your organization!

Enable Assign Return Path for bounce messages and set the Return-Path value to something like “no-reply@yourdomain.com” Note: in the event that the Agari Sensor should be unreachable, you will want to prevent SMTP bounces generated locally from traversing back to the original senders, and you should also prevent your Proofpoint system from generating duplicate copies that it queues itself. So it is advised that you choose a deliverable black-hole address for this field, meaning: an address that will not actually buffer or otherwise store the message but will simply drop it upon delivery. (Note that the Proofpoint interface does not allow setting a “<>” value here.) If you simply make up a non-existent address, Proofpoint may buffer the bounces and thus consume system resources. (If you have no such black-hole address at the destination MTA, you could create an appropriately-configured Email Firewall rule with a Discard disposition.)

The rest of the options can remain at their defaults. Your Not Spam rule will look something like the following (remember that the “X-Agari-Authentication-Results” header shown in the image below should not be added unless the instance being configured is a perimeter MTA):

Click Save Changes. Then confirm that the rule appears in the Spam Rules list:

You can confirm the traffic flow by logging into Agari’s Advanced Threat Protection portal at https://ep.agari.com and navigating to the Sensors status page. It may take some time for data to begin to appear.

If you don’t have Spam Detection enabled in your Proofpoint system, and for whatever reason do not wish to enable it, you can achieve something similar using the Email Firewall. Briefly: you add a new rule, create a condition that restricts the rule to just the inbound email policy route, make sure the Delivery Method is set to Continue, and configure the other options as described above for the Spam Detection rule. By default, the new Email Firewall Rule will be added as the last entry. This may be appropriate, but care should be taken with respect to the other rules to make sure that all mail that makes its way through the Proofpoint filters is delivered to the Sensor. For example, in the default, Proofpoint configuration, senders that are on the trusted list receive a disposition of Deliver Now which will cause all following rules to be ignored, including the agari_sensor Send a copy rule. You can solve this problem for any such rules by editing them, enabling the Send a copy to a destination option following the same pattern as described above, and otherwise preserving their existing settings.

Note also that using an Email Firewall rule instead of the Spam Detection rule may cause spam to be sent to the Agari Sensor; this could be acceptable but may have performance implications for either your Proofpoint system or the Sensor, depending on the volume of spam you process.

Enable SPF Assessment and optional Header

Note: This SPF section applies only to Proofpoint systems that are functioning as perimeter gateways.

Agari’s analysis of the email messages coming into your enterprise is improved when SPF (Sender Policy Framework) checking is performed on each message. This checking must be performed as messages arrive at your perimeter gateway(s) and the results added to the messages’ headers prior to relaying them further internally. In order to generate the associated X-Agari-Authentication-Results email headers, SPF must be enabled on the perimeter Proofpoint system(s).

Navigate to the Email Firewall > SPF > General menu.

Once there, enable SPF by clicking the On radio button. You can configure Proofpoint to disable SPF checking for certain policy routes, as desired. (For example, by default it will not evaluate SPF for outbound mail.) As long as the inbound mail is being checked, the Agari Sensor can do its job.

Your SPF settings may look something like this:

Click Save Changes to commit the settings.

Encrypting Messages to the Sensor

In some cases, your Sensor may not be within your trusted network, and you do not wish to send an unencrypted email across the public Internet. The Agari Sensor can accept TLS-encrypted connections (over port 25, via “STARTTLS”), but you will need to configure Proofpoint to do so.

TLS Encryption must first be enabled in the System > SMTP Encryption > Settings menu. Full configuration of TLS is beyond the scope of this document, but your settings might look something like this:

Note that enabling TLS Encryption may have performance implications for your Proofpoint system: once enabled, Proofpoint defaults to using TLS when it is available. This may or may not be desired. For example, if Proofpoint is relaying received mail to other servers that live safely within your private network, you may not want to encrypt those internal connections. You can configure which servers will and won’t connect via TLS.

Once TLS is enabled, Proofpoint will use TLS when it can, so it should start encrypting the mail stream to the Sensor, but if you want to be certain that the connection is encrypted, you can add an explicit rule by going to System > SMTP Encryption > TLS Domains.

Click Add to add a new TLS Domain, enter the IP address of your Sensor, and configure the options in the window to look something like this (again, your choices may vary according to need):

You can repeat that process for each Sensor your system will connect to: some may require TLS, some may not.

If you prefer to keep your regular email stream to internal mail servers unencrypted, you can add another TLS Domain for each server and set the Encrypted value to Never.

Confirm that desired system alerts are in place

If you followed the above instructions, your system should handle a temporary connectivity problem with the Agari Sensor without generating bounces to either the original senders or to an address in your own system. But it will still be queueing messages bound for the Sensor. If a short connectivity outage is anticipated, this may not be a problem. In the event of a longer outage, you will probably want to disable the Rule that sends the copies to the Sensor.

Agari recommends that you confirm that your Proofpoint system is configured to alert you when SMTP queues are getting too large. In System > Alerts > Rules you can confirm that the SMTP queue above threshold is a subscribed alert and that someone will receive such alerts if they occur. Additionally, you can adjust the Timeout value for the SMTP Profile, as described in the instructions above, to instruct the Proofpoint servers not to spend too much time attempting to deliver messages to the Sensor.

Consider other whitelisted email streams

You may have firewall rules in place that whitelist upstream MTAs sending mail to your Proofpoint instance. These rules may assign the deliver now disposition to such messages. In that case, those messages will then skip spam checking, and, assuming you have configured Dual Delivery as described in this document, such messages will thus fail to be copied to the Agari Sensor (because the Dual Delivery mechanism is part of the “Not Spam” spam rule, as described above.)

Possible solutions:

You could make a duplicate of the rule you use to whitelist your upstream MTA and order the duplicate just before the original in the list of rules. Then, following the instructions at the end of the Create a Spam Detection Rule section above, change it to create a Dual Delivery stream to the Sensor for the whitelisted MTA message. After sending the duplicate message, Proofpoint will then encounter the original Deliver Now rule and deliver the message normally.
Or, instead of using the Not Spam Dual Delivery technique described in this document, you could use a Firewall Rule to create the Dual Delivery stream. (This idea is outlined at the end of the Create a Spam Detection Rule section above.) Unfortunately, that method will likely send a large amount of spam to the Sensor as well, so it is not recommended except when necessary.
Or, configure your upstream MTA to send a Dual Delivery stream as well.

Whitelist the Agari alerts server

When Agari deems an email suspicious, the Agari alerts server will send you (or a role account) and, optionally, the recipient of the email, an email-based alert message regarding the perceived threat. Besides identifying the threatening message, the alert email may contain additional information about the type or severity of the threat. Furthermore, in case of operational problems, the Agari alerts server may also send out alerts regarding your Sensor and the overall health of your Advanced Threat Protection service. Given the importance and utility of these alerts, Agari recommends that you whitelist the Agari alerts server to ensure that your system does not block, quarantine, or otherwise interfere with these messages.

The messages that the Agari alerts server sends may sometimes contain portions of the content of the original messages. Since the original messages may contain spam or otherwise be perceived as suspicious by email filtering software, it’s possible that the Agari alerts may themselves accidentally be perceived as threats. Thus it is doubly important to whitelist the Agari alerts server to prevent the triggering of False Positives in the filtering software. If there are intermediate steps filtering your email stream before it gets to the system we are configuring with this document. Example other intermediate MTAs, or other anti-phishing solutions that filter your email stream they should also be configured to whitelist the Agari alerts server. Agari’s Sales Engineering and Customer Success teams can assist with this if needed; it is generally a straightforward process.

These instructions will detail adding the Agari alerts server to your anti-spam Organizational Safe List, as well as making a firewall rule to deliver the messages without further screening. The Organizational Safe List addition may be unnecessary given the Email Firewall Rule, but given the importance of these messages, both methods are recommended.

First, open the Spam Detection menu and click on Organizational Safe List. Click on Add to add a new List Entry. A window will appear Change the Filter Type to Sender IP Address, the Operator to Equals, the Value to 198.2.132.180, and for the Comments field enter something like “Whitelist Agari alerts server”. The window should look something like this:

Double-check to make sure the IP address value is correct, and then click Add Entry. You should see the new entry in the Organizational Safe List.

On the left side of the screen, open the Email Firewall menu, and click Rules. This will bring up the list of firewall rules. Click Add Rule. On the next screen that appears to fill out the fields as follows:

For Enable, select On. For the ID, enter something like agari_alerts. For the description, enter something like “Whitelist Agari alerts server”.

Under Policy Routes, select Restrict processing to selected policy route. The idea here is to apply this rule only to inbound mail. For many users, this will mean the default_inbound policy route, but this may be different depending on how routing is set up or named in your organization. After selecting default_inbound or whatever route(s) is/are appropriate (note that you may need to scroll the list of policy routes) click the chevron to move the route(s) over to the right side, underneath Require Any Of.

In the Condition section, click Add Condition. In the window that appears, set the Condition to Sender IP Address, the Operator to Equals, and the Value to 198.2.132.180. The window should look something like this:

After confirming that the IP address is correct, click Add Condition.

Back on the new Email Firewall Rule page, change the Delivery Method to Deliver Now. Your new firewall rule is now complete, and should look something like this:

Click Add Rule. The rule should now appear in your list of firewall rules, at the bottom:

You will want to pay some attention to the order of this rule: ideally, it should be placed at or near the top of the firewall rule list, to ensure that no other firewall rule interferes with its operation. You can drag the rule to reorder it or use the up/down arrows in the Order column.

(As seen above, the IP address of the Agari alerts server is 198.2.132.180. While in the directions above the IP address was explicitly listed, a possible option for you will be instead to reference the alert server by its hostname outbound.agari.com. However, you should only do this if you are certain that the system will act upon the client IP address of the message, and that only a forward DNS lookup is used on the Agari alert server's hostname. If you have any doubt, use the IP address.)

Adding X-Agari-Authentication-Results in a perimeter gateway

This section is intended only in cases where the Proofpoint system your are configuring is a perimeter gateway and is not being used for Dual-Delivery. If you are using your Proofpoint system to generate the Dual Delivery stream, then do not use this section, and instead follow the above instructions, which include the proper way to add the X-Agari-Authentication-Results header in that case.

If your Proofpoint system is a perimeter gateway and you want to add the X-Agari-Authentication-Results header, these instructions will assist you:

On the left side of the screen, open the Email Firewall menu, and click on Rules. This will bring up the list of firewall rules. Click Add Rule. On the next screen that appears to fill out the fields as follows:

For Enable, select On. For the ID, enter something like agari_auth_header. For the description, enter something like Add X-Agari-Authentication-Results header.

Under Policy Routes, select Restrict processing to selected policy routes. The idea here is to apply this rule only to inbound mail. For many users, this will mean the default_inbound policy route, but this may be different depending on how routing is set up in your organization. After selecting default_inbound or whatever route(s) is/are appropriate (note that you may need to scroll the list of policy routes) click the chevron to move the route(s) over to the right side, underneath Require Any Of.

In the Condition section, click Add Condition, and on the resulting dialog window, choose the Condition as Policy Route from the drop-down menu, and Operator should be set to Equals.

The Route for the condition should be set to whatever Policy Route you use to represent inbound email to your organization. The default for Proofpoint is the default_inbound Policy Route. Your organization may route differently, and a more involved setup may require more nuance with the Conditions, but the simple idea is that mail destined for users inside your organization should be caught by this set of Conditions.

(This condition is redundant in light of the “Restrict processing to selected policy routes” setting just above it, but Proofpoint requires that a Condition be specified.)

You can click Add Condition to add the condition. Alternately, if you have multiple Policy Routes representing inbound email you can click Add and New Condition, and set the next Condition to Add condition as: Or. You can add as many conditions as you need to this Email Firewall Rule to ensure that all inbound email Policy Routes are covered.

Continuing on the Email Firewall Rule creation page, in the Dispositions section, enable the checkbox next to Change message headers, and then click Add to bring up the Change Header dialog. Leave the Operation set to Add header. For Header Name, enter the string “X-Agari-Authentication-Results”, being careful to type it in exactly as shown, with no trailing colon. For the Value, enter the following string (copy and paste may be advisable), also being careful not to make any typos or alterations whatsoever, except to change “mx.yourdomain.com” (as explained in the following paragraph):

mx.yourdomain.com; spf=${SPFResult} smtp.mailfrom=${OriginalSender} smtp.helo=${Helo}

Your Change Header dialog will look something like this (note that the Value field is truncated in this image):

Click Save Changes in the dialog.

Unless you have good reason to, do not change the Delivery Method from Continue or you risk stopping incoming mail for your organization!

The rest of the options can remain at their defaults. Your firewall rule will look something like the following:

Click Add Rule. You can then confirm that the rule appears something like this in the Rules list:

That should be all that is required to add the important header. You should also confirm that the evaluation of SPF, DKIM, and any other authentication mechanisms (Sender ID, DMARC, etc.) is actually enabled so that the X-Agari-Authentication-Results header is actually populated with useful information. Please get in touch with a Proofpoint support representative if you have any questions about this process.

DualDeliverySetup-Proofpoint.pdf
700 KB Download

Create an SMTP Profile

Encrypting Messages to the Sensor

Confirm that desired system alerts are in place

Whitelist the Agari alerts server

Adding X-Agari-Authentication-Results in a perimeter gateway

Related articles