Microsoft Exchange Hosted Filtering FAQ

The IP address listed in the Admin Center must match the IP address of your mail server:

• Select the Domains option from the navigation menu in the Admin Center
• Select the desired domain name, and insert the new IP address in the field next to Inbound Mail Server
• Click the Update Domain button to save changes

Note: If you need to prioritize or load-balance mail between multiple inbound mail servers, please send an email to support@frontbridge.com with this request.

Administrators only have the ability to modify a single IP address. To add multiple IP addresses in a prioritized or load-balanced fashion, please send your request to support@frontbridge.com.

150 megabytes (150,000,000 bytes).

Reports are updated at 6 hour intervals displaying data for the previous 6 hours.

This is normal. When your mail server bounces a piece of mail, (based on the mail server's configuration) it sends a bounce message back to the sender. For example, if the server receives mail for a user it doesn't recognize, the message will bounce. Those bounced messages are blank in the FROM: field - this is an RFC standard devised to prevent the bouncing of bounce messages, mail looping, etc. Therefore, mail servers that bounce a lot of mail end up sending a lot of bounce messages, making the "BLANK" sender one of the TOP SENDER addresses for the domain.

The 4 options for Spam filtering are described below:

• SpamShark ™: With this feature, mail identified as Spam gets redirected to a secondary mailbox accessible by a web mail interface. An optional setting per domain allows users to be notified of new Spam in their SpamShark ™ mailbox, via email.
• X-header: Email is delivered normally, with a special X-Spam header that gets inserted into the mail header of the email.
• Redirect: All Spam for the domain gets directed to a company central email address.
• Subject Line: The subject line of each piece of Spam is modified to include a customizable identifier such as "SPAM:" at the beginning of it.

To change the way we filter your Spam:

• Choose the Domains option from the navigation menu in the Admin Center
• Select your domain and click the Spam filter tab at the top of the page
• Confirm there is a check mark indicating that Spam Filtering is enabled
• Click the pull down menu and highlight the filtering option desired
• Click Update Domain

To disable Spam filtering for a specific user:

• Access the Admin Center and choose the “Domains” option from the navigation menu
• Click on the Spam filter tab at the top of the page
• Check the "Allow User Opt-out" box and click the Update Domain button
• Click on the “Accounts” link in the navigation menu and select the user
• Select the “Off” radio button under Spam Filtering in the upper-right corner of the accounts page
• Click the Update Account button

While all of the CSFM options have very effective uses under the right scenarios, there are several found to be most useful. Image links to remote sites is likely one of the best options available since this type of activity is almost never used in valid email messages. Additionally web bugs in HTML, Empty Messages and Sensitive Word List are some additional options which are rarely found in legitimate mail and will stop certain obvious spam messages.

Test mode is used for determining functionality of certain CSFM options and finding which options work best for your filtering needs without actually stopping the flow of messages. By using the BCC address in combination with either modified X-Header or Subject Lines you will effectively know that a message would have been stopped by a particular CSFM option without actually having the message blocked. This will allow you to gage which rules work best for your particular email needs.

The default notification period is 7 days.

If you click on the Glossary link on the left hand side of the Spam Filter window, a pop up window will appear listing the spam attributes and their respective definitions.

When the CSFM option is enabled in Test Mode, the attribute names can be lengthy to state in the subject line. We will add with the corresponding number in brackets so the administrator can reference which CSFM option it was tagged under.

No, you cannot add or delete the words from the sensitive word list. You can, however, add your own words by creating a reject rule in the policy filter.

No, you can not customize the message body, but you can change the notification address and subject. You can, however, customize the body of the message for the TEXT notification type.

Please forward a copy of the spam message along with full internet headers to our Spam team at abuse@frontbridge.com. One spam message per submission, please. Submitting a group of messages in an attachment is not the best way as much of the original spam message can be lost.

Please forward a copy of the message along with full internet headers to our False Positive team at false_positive@frontbridge.com. They will review the message and adjust our filters where needed to prevent the exact message from being tagged as spam moving forward.

Note: You may also select the “Salvage” or “Do not block” options for the message in from your SpamShark account or HTML notification.

Ensure the “Allow users to log in to SpamShark” checkbox on the Spam Filter tab is enabled. Under Accounts, search for the users you don’t want to receive the notifications and turn off the spam notifications directly from their account via the “Spam Notifications” radio button.

To always accept mail from a domain:

• Click on Add New Rule from the Policy Filter screen
• Select Inbound from the Type pull-down
• Select Allow from the Action pull-down
• Proceed to the Sender Domain field in the Parameters section to enter the domain you wish to allow mail from
• Click Save Rule to add the rule

Note: Messages allowed in this fashion bypass the Spam filter and any policy reject rules, but they are still scanned by the Virus filter.

Note: The same can be applied to a specific email address instead of an entire domain.

To always reject mail from a domain:

• Click on Add New Rule from the Policy Filter screen
• Select Inbound from the Type pull-down
• Select Reject from the Action pull-down
• Proceed to the Sender Domain field in the Parameters section to enter the domain you wish to allow mail from
• Click Save Rule to add the rule

Note: The same can be applied to a specific email address instead of an entire domain.

To block a non-English character set:

• Click on Add New Rule from the Policy Filter screen
• Select Inbound from the Type pull-down
• Select Reject from the Action pull-down
• Proceed to the Allowed Character Sets area of the Parameters and move the undesired character set(s) to the Blocked Character Sets area
• Click Save Rule to add the rule

To reject messages containing a specific filename:

• Click on Add New Rule from the Policy Filter screen
• Select Inbound / Outbound from the Type pull-down
• Select Reject or Allow from the Action pull-down
• Proceed to the Attachments area and in the Filenames section enter all the filenames you would like to block / allow
• Click Save Rule to add the rule

To reject messages containing a specific file type:

• Click on Add New Rule from the Policy Filter screen
• Select Inbound / Outbound from the Type pull-down
• Select Reject or Allow from the Action pull-down
• Proceed to the Attachments area and in the File Extensions section enter all the extensions you would like to block / allow
• Click Save Rule to add the rule

To reject messages containing a specific keyword:

• Click on Add New Rule from the Policy Filter screen
• Select Inbound / Outbound from the Type pull-down
• Select Reject from the Action pull-down
• Proceed to the Message Subject and / or Message Body section and enter the word(s) you wish to reject
• Click Save Rule to add the rule

To block messages over a specific size:

• Click on Add New Rule from the Policy Filter screen
• Select Inbound / Outbound from the Type pull-down
• Select Reject from the Action pull-down
• Proceed to the Maximum Size box in the Parameter section and choose a size in bytes
• Click Save Rule to add the rule

Note: The maximum size is in bytes. For example, if you wish to reject messages exceeding 4 megabytes in size, you would enter 4000000 in the Maximum Size portion of the policy rule.

Yes, when creating your policy rule, select the “Search zip/compressed files” checkbox in the Attachments area.

Note: This does not apply to password protected archives.

A Test Rule can be used to qualify a rule without actually affecting the flow of email. Any message that would have triggered the rule will be delivered normally and appended with a rule-specific flag notifying the recipient that it would have been blocked if the rule was not in Test Mode. Test Mode notifications can be inserted into either the X-header of a message or in the subject line. A BCC can also be enabled if an administrator wishes to receive a copy of the messages for troubleshooting purposes.

Yes. Through the use of regular expressions, you may use wildcards in the Message Subject or Message Body area. Please consult the Instruction area in the policy rule creation area for further information.

All rules take effect at the top of the hour plus a propagation period of approximately 30 minutes.

There is no limit on the number of policy rules you can create.

There are two possible scenarios why it appears you may have received a virus. The first is that the virus you received is a new variant and our anti-virus partners have not yet released a pattern file for us to deploy. The time it takes for a patch to be released to us is completely dependent on our anti-virus partners. Our servers check for new virus definitions every 10 minutes. Once we obtain the patch, it takes approximately 1 minute for it to propagate across our entire network.

The second scenario, and most likely, is that the attachment received does not contain any active malicious code. In these situations, some anti-virus engines that run on desktops may be more aggressive and stop messages with truncated payloads.

If you are unsure about a specific message you received, please submit it to Technical Support (support@frontbridge.com) for investigation.

We receive updated virus definitions every 10 minutes. Once received, it takes approximately 1 minute to fully propagate them across our network.

We strongly advise that you do not open any attachments that you do not recognize. If you would like us to investigate the attachment, email the virus to Technical Support at support@frontbridge.com within a password protected zip file.

The messages contain active malicious code and therefore we do not allow access to these messages. They are simply blocked.

Using a layered approach to antivirus for both inbound and outbound e-mail, Exchange Hosted Filtering has partnerships with numerous best-of-breed providers of antivirus technologies.

All of our customers are automatically protected by at least three of our virus partners at all times. There is no way to choose one AV engine over another.

No. Policy allow rules do not bypass the virus filter. If you would like this attachment to bypass the virus filter, please ensure it is sent within a password-protected zip file.

Either Directory Services is not enabled for the domain in :

• Go to the domain on the ‘Manage Domains’ page of the Admin Center and ensure the Directory Services tab is enabled and is turned on
• If this is not enabled, you will need to contact support to have this feature enabled

Or your account does not have the appropriate permission to upload directory services list:

• Click on the ‘My Account’ link at the top of the Admin Center
• Ensure you have the Directory Services Area permissions for the domain or organization you are attempting to upload for

Disable the Account:

• Search for the account uploaded to the Admin Center on the ‘Manage Accounts’ page
• Click ‘Disable Account’. This removes the account from the uploaded DS list as well

This option is not available in the Admin Center. Technical Support has to disable the list in the AC for the list to be completely removed.

Propagation time for Directory Services is approximately 15 minutes.

When appending a new account to your reject test directory services list, you will always need to add the catch all account after the new account upload to ensure the catch-all relationship is maintained.

Yes. When you upload a Directory Services list using the Admin Center Upload mode, Spam Quarantine accounts are created automatically for each user. However, if you choose to upload a Directory Services list using other upload modes (for example, the Directory Synchronization Tool or SFTP), you will need to add Spam Quarantine accounts manually using the Admin Center.

Using Directory Services can greatly reduce the amount of unwanted email messages you receive. Although we do block 90-95% of spam messages, some spam messages may not be caught by our spam filters. Using Directory Services may prevent that small percentage of from being passed on to you. Creating the Directory Services upload list does require some additional work but it will give you complete control over who you allow to receive mail on your network.

Reject type directory services lists will also aid greatly in protection against denial of service attacks, by having our service reject all email for invalid users.

Directory Services is not related to or affiliated with Active Directory, although in most cases your Directory Services list will be similar or identical to your Active Directory accounts.

By default, if you have not uploaded a Directory Services user list we will accept and deliver mail addressed to anyone on your domain(s).

Pass through mode will allow you to test the filtering services on a subset of users that are included on your Directory Services list. Mail destined for users not included in the pass through list will bypass our filtering services and be delivered to the recipient.

Directory Services Test Mode will make it possible to see what mail would be rejected if you used Reject mode. Directory Services Test Mode forwards all mail that is addressed to people not on the Directory Services list to the very last person on that upload list.

You would need to re-upload your account list and change the account type to Directory Services Reject.

The sender of the email is notified with a 554 error message that the message they tried to send was not delivered to the intended recipient:

Example: 554 <invaliduser@domain>: Recipient address rejected: Access denied

No, you need to contact your DNS provider and request any DNS changes through them.

There are 3 records primarily used for Email. Mail eXchange (MX), Pointer (PTR) and Sender Policy Framework (TXT). Please see below for additional information on each type.

CNAME is short for Canonical Name. A CNAME record is an alias to a real name of a machine. A machine can have multiple CNAME records.

No, CNAME records are aliases for names of servers so that a server can have multiple names. We however route to you directly to your server via the information you provide us in the Admin Center.

No we do not have a CNAME record.

The Mail eXchanger record (MX record) tells mail systems how to handle mail that is addressed to a particular domain. It tells the sending mail server where to send the mail.

It should point to Mail.Global.Frontbridge.Com. This will ensure that mail sent to your domain is relayed to us for filtering.

Yes. If your organization has multiple domains for which you receive e-mail, you will need to change the MX record for each domain you wish us to filter mail for.

Your MX record will take 72 hours to fully propagate throughout the Internet.

After we have provisioned your account. This means we have verified that we can contact your mail servers via SMTP, you have been through an Admin Center configuration walkthrough, and you have configured your mail servers to point to us for outbound mail (if you have purchased this service).

Any additional domains should be created in the Admin Center before changing the MX record. If the MX record is changed before the domain is created and propagated, the mail destined for that domain will bounce.

Yes you can. Though it is highly unlikely that all of our servers would go down you can set up your MX to have mail.frontbridge.com listed as priority 10 and you server as priority 20. You would need to make sure that your server is capable of receiving email. We do not recommend this however, as it allows spammers to bypass us and force mail to the other MX record.

If the sending server is using Exchange then yes it will automatically send to the highest priority, but if the sending MTA is using Send Mail, Postfix or a Unix based email system then that is not the case.

A PTR (Pointer Record) is a record that is used for Reverse DNS. It is the opposite of an A record and is used in Reverse Map zone files to map an IP address (IPv4 or IPv6) to a host name. When you send email to a location they receive your IP and check your PTR record to verify that the IP equals your domain.

We suggest that you have one. If you do not then some domains will not accept email from you.

Sender Policy Framework is a relatively new record that is used to help prevent email spoofing. It allows you to specify all of the IP’s that you would send from in one simple TXT record and to tell the receiving server to only allow the outbound servers you listed.

Yes. If you send exclusively through us then you would need your SPF (TXT) record to look like this;

“v=spf1 include:spf.frontbridge.com –all”

This TXT record would only allow sending for your domain from our servers and stop any one else who tried to pretend (Spoof) to be you (Spoof)

All Sender Policy Framework checks is the actual TXT record to see if the sending IP is listed as an allowed IP for your domain. This was created as a much needed alternative to the PTR method of reverse DNS checking. So a TXT record is created with the following attributes.

Format of TXT:

“V=spf1 mx ip4:{any server you may also send from IP} include:spf.frontbridge.com ~all”

V=spf1 – This is the version of spf that is being used.
MX – this says that you are sending also from everything listed on your MX record
IP4 – This is for any server IP that you also allow for (Not needed for our servers if you included our SPF record and send only through us)
Include – Includes additional records to allow sending for your domain
All – All has three switches that it starts with.
- Means do not accept any mail from anyone other than listed above, hard fail.
~ Means do not accept any email that does not come from one of the above allow but soft fails the email.
? Means there are more servers that may be sending from our domain.

A normal TXT for a client who sends only through us would look like the following: "v=spf1 include:spf.frontbridge.com -all"

Transport Layer Security (TLS) is an Internet standard protocol used to secure communications over a network by means of encryption. In a messaging environment, TLS is used to secure server-server and/or client-server communications.

TLS provides services such as data integrity, confidentiality and non-repudiation by means of authentication and encryption. Masquerade attacks, man-in-the-middle, rollback attacks, and replay attacks are mitigated by using TLS. In the messaging environment TLS is primarily used to ensure confidentiality of a message during its transmission over the network.

The keyed-hashing for Message Authentication Code (HMAC) algorithm replaces the SSL Message Authentication Code (MAC) algorithm to increase the strength of the hash.

Many new alerts and error messages have been added to assist with troubleshooting and implementation.

Intermediary trusted Certificate Authorities (CA) can be used to validate certificates without having to check the master CA.

TLS can be extended to include additional authentication methods and encryption algorithms.

TLS improves performance over SSL by using secure session caching.

Yes. Our service is designed to always try a TLS connection first when receiving or sending mail. If TLS is not supported on the remote server, we will failback to using standard SMTP without TLS.

A TLS handshake can fail for several reasons; the more common scenarios are as follows:

The TLS/SSL certificate used in the handshake has expired or been revoked.

Your server does not have the most current version of the GTE Cybertrust Global Root certificate installed.

The firewall handling the connection may not be configured to allow TLS communication through port 443.

Also, the extensive error reporting used in TLS is an excellent way to troubleshoot any handshake or connectivity problems you may encounter.

Certificates should be purchased directly from a Certificate Authority (CA) or from an authorized certificate reseller.

The certificate needed for our service is the standard X.509 TLS/SSL certificate. Please note that you must have the most current GTE Cybertrust Root certificate installed along with your certificate.

Our service supports TLS key sizes of up to 2048 bits. The key size more widely used today is 168 bits.

No, you do not need to alert us as our system is configured to automatically use TLS if your server requests it.

If TLS is configured with a certificate on your server, all incoming and outgoing mail between our datacenters and your network will be TLS encrypted. If your server supports TLS, only messages sent from your server to our datacenters will be encrypted.

No, this only works for mail in an intranet environment as your certificate will not be trusted by the public root GTE Cybertrust certificate.

Your mail server must have the TLS/SSL protocol stack installed (installed by default with most new operating systems) and it must be setup to initiate SMTP connections using TLS. Also, you must have the most current GTE Cybertrust certificate installed.

Most firewalls are pre-configured to allow TLS/SSL traffic on port 443. Please consult your firewall vendor if you are unsure if your firewall supports this or if it needs to be configured.

There are 2 basic ways to tell if a server is TLS capable. The first is to send and receive a message from the server and then to examine the headers on the message. If you see anything TLS related, the server more than likely is TLS enabled.

The second basic method is to test the server by using a Telnet connection. Below is an example of a Telnet session into one of our datacenters that shows the STARTTLS option. You may perform this test on any mail server. The following example was taken from our servers:

CMD: telnet mail.global.frontbridge.com 25

220 mail77-red.bigfish.com ESMTP Postfix EGGS and Butter

CMD: ehlo test

250-mail77-red.bigfish.com
250-PIPELINING
250-SIZE 150000000
250-ETRN
250-STARTTLS
250 8BITMIME

CMD: starttls

220 Ready to start TLS

The “220 Ready to start TLS” indicates that the server is ready to start a TLS connection.

Mail servers may or may not “stamp” a message indicating it was TLS encrypted. If it was “stamped” you will see a line in the message headers similar to:

"using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)"

The above example shows which algorithms and bit sizes were used to encrypt the message.

Yes, your message will still arrive, but it will be delivered via standard SMTP protocol.

From the Organization page, scroll down the page to Domain Setup; click the “Add Domain” button. Hit “Update Domain” to save your changes.

If you have customized the settings for an existing domain, you can use the template to copy the same setting over to the new domain that is being added to the Admin Center.

Checking the box will enable the “same mail distribution profile” and will copy the delivery SMTP profile over from the domain selected from the Template.

No, add your domain to the Admin Center first. Next, set up your SMTP profile for the new domain or you can use the template. Click on Update domain to save your changes. The change will take in effect at the top of the hour plus 30-35 minutes to prorogate and for the new domain to be recognized across all of our data centers. After that time, you can then change your MX record for the new domain added to point to us.

Please contact your sales rep for information.

No, each domain can be set up to have its own SMTP profile for inbound and outbound mail. A Multi-SMTP profile can also be used for inbound mail. To add additional inbound IP addresses, please contact Technical Support at support@frontbridge.com.

No, you can use the Template Manager on the Organization page of the Admin Center. This will carry over the same setting of a previously customized domain onto and domains you have selected on the right hand side of the drop down box.

If you have administrative permissions to the Admin Center, you can add the domains yourself.

Domains cannot be deleted from the Admin Center but can be disabled. To disable a domain, select Manage Domains, the Main tab and remove the check mark from the enable box. Click the “Update” button to save your changes. You will also need to change the MX record for the disabled domain.

Note: If the MX record is not changed before the domain is disabled, all mail destined for that domain will bounce.

You add your sub domain separately on the Organization page by selecting the “Add Domain” link or you can use the “Catch All Domain” feature in the Manage Domains section, on the Main tab. Enabling “Catch All Domain” will filter and handle your sub domains as per the settings of the parent domain. The MX record for the sub domain will also need to point to us.

If a domain is marked disabled in the Admin Center, but the MX record is pointing to us, all mail will be bounced back to the sender.

No, you will need to create each “batch” of domains separately.

Messages will become queued or “deferred” if Microsoft we are unable to make a connection to the recipient server for delivery.

Note: We will not defer messages if a 500 series error is returned from the recipient network.

Messages will be held when a connection to the recipient server can not be made and the recipient’s server is returning a ‘temporary failure’ such as a connection time-out, connection refused or a 400 series error. If there is a permanent failure, such as a 500 series error then the message will be returned to the sender.

Messages in deferral will be held for up five days before returning to the sender. An attempt will be made to resend messages approximately every twenty minutes during this period. If a 500 series error/permanent failure is returned, the message will be removed from the deferral queue and will be immediately returned to the sender.

It is not necessary to notify us for any server outages. Messages will begin to defer as soon as temporary failures are returned.

The errors on the deferral report indicate the reason each message was being deferred.

A notification will be emailed out to the sending party after two hours of a message being in deferral indicating that the recipient has not received the email. This is the only notification sent until the final return after 5 days.

The monitor tool in the Admin Center may be used to send warning emails to out-of-band email addresses after a predefined threshold of messages in deferral has been reached. These notifications will be sent every 30 minutes, as long as the number of messages in queue remain above the predefined threshold.

A bounce message, or Delivery Status Notification (DSN) message is created automatically when a problem occurs with delivery to the intended recipient’s mail system. This automated electronic mail message is transferred to the sender to indicate their message could not be delivered. This explains how to interpret the information provided by some common bounce messages.

The most important pieces of information included in bounce messages of this type are the sender and recipient addresses, date of delivery, the host name or IP address that generated the bounce message, and the Reply and Status Codes. Troubleshooting varies depending on the error that generated the bounce message, indicated by the Reply and Status Codes.

Here is an example bounce message:

Italicized text indicates default information that can be customized by the Administrator of the mail server that created the bounce message.

Underlined text indicates information that is reliant upon the information contained in the original message and pertaining to the specific error experienced when delivery was attempted.

From: MAILER-DAEMON (Mail Delivery System) [Originating Address (Mail Delivery System)]
Sent: Day, Month Date, Year Time
To: Sender Email Address
Subject: Undelivered Mail Returned to Sender

This is the Postfix program at host Sender Mail Server.

I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can delete your own text from the attached returned message.

The Postfix program

<Recipient Email="" Address="">: host
Host name that generated the error [Host IP that generated the error] Wording for specific error message: Reply Code Status Code Recipient Host Name Error Description

A complete list of Reply Codes can be found in RFC (Request For Comments) document 821.
A complete list of Status Codes can be found in RFC (Request For Comments) document 3463.

Sometimes an electronic mail message needs to be transferred or relayed across multiple computers or servers on the Internet in order to reach its intended destination. For security purposes many computers or servers on the Internet restrict the IP addresses and/or domains they will accept electronic mail messages from or relay messages for. If a computer or server on the Internet refuses to transfer a message it will create an error message that will be returned to the sender of the refused message.

The most important pieces of information included in bounce messages of this type are the sender and recipient addresses, date of delivery, and the host name or IP address that rejected the message. In order to resolve this issue the Administrator of the host that rejected the message must be contacted.

Here some common examples of this type of bounce message:

Italicized text indicates default information that can be customized by the Administrator of the mail server that created the bounce message.

Underlined text indicates information that is reliant upon the information contained in the original message and pertaining to the specific error experienced when delivery was attempted.

Example 1:

From: System Administrator
Sent: Day, Month Date, Year Time
To: Sender Email Address
Subject: Undeliverable: Subject from the original message

Your message did not reach some or all of the intended recipients.

Subject: Subject from the original message

Sent: MM/DD/YYYY Time

The following recipient(s) could not be reached:

Recipient Email Address on MM/DD/YYYY Time

There was a SMTP communication problem with the recipient's email server. Please contact your system administrator.

<Host name="" that="" rejected="" the="" message="" #5.5.0="" SMTP=""; 554="" Recipient="" Email="" Address="" >: Relay access denied>

Example 2:

From: MAILER-DAEMON [MAILER-DAEMON]
Sent: Day, Month Date, Year Time
To: Sender Email Address
Subject: Undelivered Mail Returned to Sender

This is the Postfix program at host Server that rejected the message.

I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can delete your own text from the attached returned message.

The Postfix program

<Recipient Email="" Address=""> : host Host name that rejected the message [IP address that rejected the message] said: 554 <Recipient Email="" Address=""> : Relay access denied (in reply to RCPT TO command)

A complete list of Reply Codes can be found in RFC (Request For Comments) document 821.
A complete list of Status Codes can be found in RFC (Request For Comments) document 3463.

When the server that handles incoming electronic mail messages for a recipient is busy or unable to accept messages sometimes the undelivered messages will be placed in a queue on the host or server that is being used to deliver these messages. In these cases a notification is generated to alert the sender of the delay in delivery.

The most important pieces of information included in bounce messages of this type are the sender and recipient addresses, date of delivery, and the name or IP address of the host where the message has been delayed. In order to resolve this issue the Administrator of the intended recipient mail server must be contacted.

Here is an example of this type of notification.

Italicized text indicates default information that can be customized by the Administrator of the mail server that created the notification.

Underlined text indicates information that is reliant upon the information contained in the original message and pertaining to the specific error experienced when delivery was attempted.

From: Administrator of Host where message is delayed [Email Address of Administrator for Host of where message is delayed]
Sent: Day, Month Date, Year Time
To: Sender Email Address
Subject: Delivery Status Notification (Delay)

This is an automatically generated Delivery Status Notification.

THIS IS A WARNING MESSAGE ONLY.

YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Delivery to the following recipients has been delayed.

Recipient Address(es)

Individual policy rules can have their own bounce messages created to send back to the sender of the message.

To enable the bounce message for a policy rule follow these steps:

• Click Add New Rule or on the Rule ID.
• Enter in the parameters of the policy rule.
• Select Send Bounce in the bottom of the screen on the left side.
• Optional: Enter in the Bounce Subject. The default subject will be “Undeliverable message returned to sender” if this field is not filled in.
• Optional: Enter in the Bounce Text. The default body text will be: “This message was created automatically by mail delivery software.Message violated a policy rule set up by the domain administrator. Delivery failed for the following recipient(s):recipient@domain.com”
• Optional: Enter in the Bounce From. The default from would be “Policy Filter”.
• Optional: Enter in the Bounce Address. The default would be blank.
• Click Save Rule.