Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Quarantine Notification per User

Hi,

Is it possible to activate the Quarantine Notification per Domain or per User?
So that User a@b.com gets a Notification, if an email arrived in his quarantine, but User b@b.com doesn't get a notifications for his quarantine?
Until now i found only the option to activate or deactivate Notifications for the whole machine.

13 REPLIES
New Member

Re: Quarantine Notification per User

I am interested in this also so posting a reply so I can be notified of any further discussion.

Re: Quarantine Notification per User

I don't know how your configuration looks like...

The following way could be very time-consuming, having a lot of users administrated by table oder very easy by administrating with ldap.

On my configuration i just added two content filters which check the mails for executables and stuff like that.
After that you have to create two ldap groups. One of them contains the users which will be notified if they're recieving a blocked email and the other one contains the rest of the users which will not be notified.
Now you have to add the condition "envelope recipient" and modify the rule to notify or even not.

I hope my post will help you!


Greetz,
Sven

New Member

Re: Quarantine Notification per User

thanks for your answer.

i'm talking about the ironport spam quarantine. (in the monitor menu).
there i can enable and disable the quarantine, can choose an authentication method for end user access and can enable spam notifications.
however, this notifications are global. what i want to do is to say:
user a@example.com gets a notification every day, when there is spam in his quarantine.
user b@example.com doesn't get a notification at all.

i see a possibility with message filters and rcpt-to-group. however, this is message-based. does the ironport send the spam notifications as single messages?

perhaps i could use a message filter of content filter saying (if subject == "IronPort Spam Quarantine Notification" AND rcpt-to == "b.expample.com")
{drop},
but that would be really painfull to administrate, if it is working (is the mail queue from mails that the ironport itself is sending the same as for normal mails? i don't think this messages are going through the spam-filter)

New Member

Re: Quarantine Notification per User

what you can do is make a content filter catching the outgoing notifications

New Member

Re: Quarantine Notification per User

this doesn't seem to work. i tried catching reports, that i was generating. I think the problem is, that this emails, which are send directly from the appliance, don't go in the normal Email pipeline. (seems logical - no use in virus scanning or spam checking emails that the appliance itself send). So no content filter is working.
Well, the next possibility would be to fetch these messages on the mailserver.
thanks alot.

New Member

Re: Quarantine Notification per User

It works for me as an "Incoming Content Filter", we have an M-Series sending the reports

New Member

Found a procedure that may work for you!

This involves the M and the C series, appears tedious but will provide what you are looking for.

The IronPort's ISQ notifications by default will go to individual users that have spam quarantined in the ISQ.  When ISQ notifications are enabled, there isn't anything that can be done to prevent the end users from seeing these notifications.
Some customers only want to allow ISQ notifications for a small subset of their users.  Currently this is not possible, but can be achieved with the workaround outlined below.


The problem is not the M series or the ESA.  By design, the ESA is aware of the locations of the quarantine server. When the ISQ is located off-box, the unit references its configurations to allow it to recognize any remote inbound connection from the IP address of its quarantine server as released emails or ISQ notifications.  Any traffic from the quarantine server is allowed to skip the work queue. Since the work queue is skipped, message or content filters can't be used to filter these notifications.

ISQ: MID 474 was released from 10.92.152.37
ISQ: Delivering released MID 474 (skipping work queue)

There is a workaround for M series appliances to ensure the work queue is not skipped. The M series can be modified to direct traffic to the ESAs via a different IP address, other than one it receives spam traffic on. As a result, the M series quarantine server will originate its traffic from the an IP address that the ESA is not aware of.

Steps to achieve this:

M-Series steps:

1.  Add a secondary IP address to the M series.
    a. The IP address must have a /24 network mask
    b. The original IP of the M series must be swapped to a /32 netmask

       Currently configured interfaces:
        1. Management (10.92.152.37/32 on Management: gloop.run)
        2. outbound_gloop_ISQ_notify  (10.92.152.20/24 on Management: NEWIP.goop.run)
  

2.   Bind the quarantine server onto the second IP '10.92.152.20'.
   
   
    This change will be done via interface configuration when creating the new IP.
   
    Do you want to enable IronPort Spam Quarantine HTTP on this interface? [N]> Y
    Do you want to enable IronPort Spam Quarantine HTTPS on this interface? [Y]>
    Which port do you want to use for IronPort Spam Quarantine HTTPS? [83]>
   

This concludes all changes on the M series.  Please submit and commit your work.


The following changes will be made on the ESA appliance(s)

C-Series Steps:

1.  Please add the new IP address of the M series to the relaylist of the ESA appliances.

2.  Create a dictionary file to house all the recipients you will allow ISQ notifications for.

    This is done under mail policies---->dictionaries
   
    Please call it, Allow_ISQ_Notifications
    add all the users that are allowed to receive these notifications.

   
3.  Create a message filter that will filter all ISQ notifications originating at the NEW IP address of the M series.
 
The first message filter will look for connections from the New IP Address, and if it has the correct subject line, and the recipients aren’t listed in the dictionary file called 'Allow_ISQ_Notifications'

Drop_ISQ-Notification: if (remote_ip == 'NEW IP ADRESS' AND (subject == 'Nielsen Email Quarantine Notification'))
{
if NOT (rcpt-to-dictionary-match('Allow_ISQ_Notifications'))
{
quarantine('Policy');
}
}


4.  Create a second message filter for released emails that originate from the NEW IP address of the M series.

   This will ensure that released messages are not rescanned by the spam engine, antivirus engine, but instead are delivered to the final recipient.
  
  

 Deliver_released_messages: if (remote_ip == 'NEW IP ADRESS')
 {
 skip-spamcheck();
 skip-viruscheck();   
 deliever();
 }


Submit and commit

New Member

I tried the steps described

I tried the steps described above but it only broke connectivity between SMA and ESA.

 

Another way to avoid spam notification:

Create a new incoming policy, in the antispam settings, choose for action "deliver" instead of "quarantine" and add a custom header to the message.

On the SMA, create a new quarantine.

Create a content filter that identified messages with the custom header and send them to the new quarantine. You will avoid spam notifications for the people matching your new policy.

New Member

Found a procedure that may work for you!

This involves the M and the C series, appears tedious but will provide what you are looking for.

The IronPort's ISQ notifications by default will go to individual users that have spam quarantined in the ISQ.  When ISQ notifications are enabled, there isn't anything that can be done to prevent the end users from seeing these notifications.
Some customers only want to allow ISQ notifications for a small subset of their users.  Currently this is not possible, but can be achieved with the workaround outlined below.


The problem is not the M series or the ESA.  By design, the ESA is aware of the locations of the quarantine server. When the ISQ is located off-box, the unit references its configurations to allow it to recognize any remote inbound connection from the IP address of its quarantine server as released emails or ISQ notifications.  Any traffic from the quarantine server is allowed to skip the work queue. Since the work queue is skipped, message or content filters can't be used to filter these notifications.

ISQ: MID 474 was released from 10.92.152.37
ISQ: Delivering released MID 474 (skipping work queue)

There is a workaround for M series appliances to ensure the work queue is not skipped. The M series can be modified to direct traffic to the ESAs via a different IP address, other than one it receives spam traffic on. As a result, the M series quarantine server will originate its traffic from the an IP address that the ESA is not aware of.

Steps to achieve this:

M-Series steps:

1.  Add a secondary IP address to the M series.
    a. The IP address must have a /24 network mask
    b. The original IP of the M series must be swapped to a /32 netmask

       Currently configured interfaces:
        1. Management (10.92.152.37/32 on Management: gloop.run)
        2. outbound_gloop_ISQ_notify  (10.92.152.20/24 on Management: NEWIP.goop.run)
  

2.   Bind the quarantine server onto the second IP '10.92.152.20'.
   
   
    This change will be done via interface configuration when creating the new IP.
   
    Do you want to enable IronPort Spam Quarantine HTTP on this interface? [N]> Y
    Do you want to enable IronPort Spam Quarantine HTTPS on this interface? [Y]>
    Which port do you want to use for IronPort Spam Quarantine HTTPS? [83]>
   

This concludes all changes on the M series.  Please submit and commit your work.


The following changes will be made on the ESA appliance(s)

C-Series Steps:

1.  Please add the new IP address of the M series to the relaylist of the ESA appliances.

2.  Create a dictionary file to house all the recipients you will allow ISQ notifications for.

    This is done under mail policies---->dictionaries
   
    Please call it, Allow_ISQ_Notifications
    add all the users that are allowed to receive these notifications.

   
3.  Create a message filter that will filter all ISQ notifications originating at the NEW IP address of the M series.
 
The first message filter will look for connections from the New IP Address, and if it has the correct subject line, and the recipients aren’t listed in the dictionary file called 'Allow_ISQ_Notifications'

Drop_ISQ-Notification: if (remote_ip == 'NEW IP ADRESS' AND (subject == 'Nielsen Email Quarantine Notification'))
{
if NOT (rcpt-to-dictionary-match('Allow_ISQ_Notifications'))
{
quarantine('Policy');
}
}


4.  Create a second message filter for released emails that originate from the NEW IP address of the M series.

   This will ensure that released messages are not rescanned by the spam engine, antivirus engine, but instead are delivered to the final recipient.
  
  

 Deliver_released_messages: if (remote_ip == 'NEW IP ADRESS')
 {
 skip-spamcheck();
 skip-viruscheck();   
 deliever();
 }


Submit and commit

New Member

Re: Quarantine Notification per User

thanks for the answer, but unfortunately there is no M-Series around here. Perhaps this is an opportunity to get one...

New Member

Re: Quarantine Notification per User

Yes, I think that options are very limited without M-Series appliance.

This is from user guide:

Messages released from the IronPort Spam Quarantine proceed directly to the destination queue, skipping any further work queue processing in the email pipeline.

New Member

Found a procedure that may work for you!

Wouldn't we want e-mails to be scanned by Virus filters when they are released?  In the time that the e-mail was sent to the quarantine, a new virus definition could be added that the initial when received virus scan did not have.  Was a situation that occurred in our environment today.   Was an isolated incident but thought I would mention here.

New Member

Hi, I found that in the ESA

Hi,

 

I found that in the ESA user guide but I'm not able to find further documentation.

"You can also enable domain-based queries for LDAP end-user access or spam notifications for the Spam Quarantine. For more information, see the Spam Quarantine chapter."

 

Have anyone already implemented this feature?

1677
Views
0
Helpful
13
Replies
CreatePlease to create content