Can't Block Mail from a Specific Sender

[Mike Kwilosz]

So I'm having an issue blocking a specific sender from emailing us.  The mail is from mail.vresp.com and the envelope sender is always something to the affect of this bounces-60ebdf6df3-088951a90a@b.cts.vresp.com

Now currently I have a content filter in place that I use for dropping unwanted inbound email.  It works great for everyone I add to it but for some reason this one specific address refuses to get blocked.  The way I have the content filter setup is it triggers on the condition "Envelope Sender" and it bases it on a Dictionary File that I add unwanted domain names too.  So for instance if I wanted to block any email in the future from microsoft.com I would simply put @microsoft.com in the dictionary file and that would do it.  Now for some reason this one specific domain @b.cts.vresp.com will not seem to get blocked.  I have tried adding @b.cts.vresp.com  @mail.vresp.com vresp.com and none seem to do the trick.  So I'm reaching out for some help.  Does anyone have any good suggestions as to how I might block this sender going forward?

Below is the header information from a message sent from this sender.  Let me know if I'm missing something.

Thanks,

Mike

Received: from  () by

() with Microsoft SMTP Server id 8.2.254.0; Mon, 15 Aug 2011

11:35:50 -0700

Received-SPF: Pass (: domain of

bounces-60ebdf6df3-088951a90a@b.cts.vresp.com

designates

  74.116.89.11 as permitted sender) identity=mailfrom;

  client-ip=74.116.89.11; receiver=ipesa01.pnshs.com;

  envelope-from="

bounces-60ebdf6df3-088951a90a@b.cts.vresp.com

";

  x-sender="

bounces-60ebdf6df3-088951a90a@b.cts.vresp.com

";

  x-conformance=spf_only; x-record-type="v=spf1"

Received-SPF: None (: no sender authenticity

  information available from domain of

postmaster@mkt2-sc.verticalresponse.com

) identity=helo;

  client-ip=74.116.89.11; receiver=;

  envelope-from="

bounces-60ebdf6df3-088951a90a@b.cts.vresp.com

";

  x-sender="

postmaster@mkt2-sc.verticalresponse.com

";

  x-conformance=spf_only

X-IronPort-Anti-Spam-Filtered: true

X-IronPort-Anti-Spam-Result: AmUEAF1mSU5KdFkLjWdsb2JhbAA1CQOCSzWBQwOERY9vhw8BhyFqFAEBAQEJCQsJEgUigUoaBgoTAwECAwUDAgwICAsBBQcfCAIcAQkCAhsWDwknGwIEh1OoDIMbgUWEaQEEAoEqgXQggXeBEIJVkEGFDItr

X-IronPort-AV: E=Sophos;i="4.67,374,1309762800";

   d="scan'208,217";a="2041549"

Received: from mkt2-sc.verticalresponse.com ([74.116.89.11])  by

  with ESMTP; 15 Aug 2011 11:34:15 -0700

Return-Path: <

bounces-60ebdf6df3-088951a90a@b.cts.vresp.com

>

DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws;

s=mkt; d=vresp.com;

h=DKIM-Signature:Received:From:Reply-To:To:Subject:Date:Message-ID:List-Unsubscribe:MIME-Version:X-Company_ID:X-vrfbldomain:X-vrpod:X-CTS-Enabled:X-Campaign:Content-Type;

b=KRtxoK8e7VkhqtjPWdDgZo16eXUASjyTPq4RMEPcSPZc9386gKM9Y205C/on2iLK

S0ZlQypXY/OZgZWGsDkAYbt+9AYfkYPg9blmB5CVLZcaPhaMCDUejHgb7MWqOlXd

4haUmfxTEnEE7BOJcQBZ3SzSZj3YWnIeieiOpyVI3/k=

DKIM-Signature: v=1; a=rsa-sha1; d=vresp.com; s=dkim; c=simple/simple;

q=dns/txt;

i=@vresp.com

; t=1313433348;

h=From:Subject:Date:To:MIME-Version:Content-Type;

bh=uuDNwk+PHTDmCjp1/xovAioRhWU=;

b=mQygs7zs3/Xe+eFNSTo79QZaqp2WviP5DcDJURuEYTwcd9w5YHQ+TGGlSdAgYiCG

ir6UygHChQcMSjQ8f4y06k260a8q8b8ZtJimN2o7zKBjd+pgFtE8Eyhcid5uBYLW

LmCfrlb0exei33+yiHJhxiVh/XTS5J0cPSyZf/suJ1o=;

Received: from [10.4.7.80] ([10.4.7.80:58830]

helo=mailer03.sf.verticalresponse.com) by demosthenes (envelope-from

<

bounces-60ebdf6df3-088951a90a@b.cts.vresp.com

>) (ecelerity 3.0.28.38595

r(38597)) with ESMTP id C7/E1-25910-407694E4; Mon, 15 Aug 2011 11:35:48 -0700

From: Tango Networks <

Tango_Networks@mail.vresp.com

>

Reply-To: "Tango Networks" <

reply-60ebdf6df3-088951a90a-631e@u.cts.vresp.com

>

To: <

>

Subject: Unique Solutions, Great Reseller Program, Let's Tango.

Date: Mon, 15 Aug 2011 18:35:48 +0000

Message-ID: <

60ebdf6df3-@mail.vresp.com

>

List-Unsubscribe: <

mailto:reply-60ebdf6df3-088951a90a-631e@u.cts.vresp.com?subject=unsubscribe

>

MIME-Version: 1.0

X-Company_ID: 647838

X-vrfbldomain: fbl.p0.verticalresponse.com

X-vrpod: p0

X-CTS-Enabled: 60ebdf6df3-088951a90a

X-Campaign: 60ebdf6df3

Content-Type: multipart/alternative;

boundary="__________MIMEboundary__________"; charset="UTF-8"

[Christopher Smith · Accepted solution]

Hi Mike,

It looks like this message may be a redirected bounce. For example someone spammed another domain and used your users e-mail address as the reply to address. If that's the case then bounce verification would fix this. Bounce verification adds a specific tag to all outgoing traffic so that if you receive a bounce we look for that tag before decided to accept it or not. If the messages are missing the tag they get dropped. This prevents you from receiving bounces for messages that did not originate from your domain. There are a couple of requirements for this.

1) you have to have a feature key for bounce verification.

2) all outbound traffic has to be routed through your appliance for this to work.

How do I configure IronPort Bounce Verification?

To configure IronPort Bounce Verification, follow these steps:

1. Enter a tagging key under Mail Policies > Bounce Verification.   (Enter the tagging key yourself, by using a random selection of numbers and letters e.g. 4r5t6y7u) .
2. Edit the bounce verification settings:
   - Enable bounce verification via Destination Controls under Mail Policies > Destination Controls.
   - Under Domain Choose Default (or the custom destination you are working on)
   - Once Default in open you will see the Bounce Verification section, click Yes
3. Ensure that you are blocking untagged (misdirected) bounces:
   - Mail Policies > Mail Flow Policies
   - You will see a list of Policies, select the appropriate policy, and then find the Security Features section
   - Ensure "Evaluate Untagged Bounces" is set to 'No' or on  earlier versions of AsyncOS "Accept Untagged Bounces:" should be set to  'No'

Overview of Tagging and IronPort Bounce Verification:

When  sending email with bounce verification enabled, your IronPort appliance  will rewrite the Envelope Sender address in the message. For example,  MAIL FROM: joe@example.com becomes MAIL FROM: prvs=joe=123ABCDEFG@example.com.  The 123... string in the example is the "bounce verification tag" that  gets added to the Envelope Sender as it is sent by your IronPort  appliance. Enter a tagging key under Mail Policies -> Bounce  Verification (see Configuring Bounce Verification Address Tagging Keys  in the Advanced User Guide for more details). If this message bounces,  the Envelope Recipient address in the bounce will typically include this  bounce verification tag.

You can enable or disable bounce  verification tagging system-wide as a default. You can also enable or  disable bounce verification tagging for specific domains. In most  situations, you would enable it by default, and then list specific  domains to exclude in the Destination Controls table (see Working with  Destination Controls).

If a message already contains a tagged  address, AsyncOS does not add another tag (in the case of an IronPort  appliance delivering a bounce message to an IronPort appliance inside  the DMZ).

Note that enabling IronPort Bounce Verification may  cause your IronPort appliances to reject legitimate mail that is sent  with a blank Envelope Sender. See IronPort Bounce Verification and  Sending Mail Between IronPort Appliances for related information.

As for the filter it would normally be something like if sender ends with b.cts.vresp.com

Christopher C Smith

CSE
Cisco IronPort Customer Support 

[Mike Kwilosz]

Christopher,

Thank you for the reply.  I checked our appliances and noticed that this was not applied to them.  I've gone forward with implementing it.  I hope this will resolve our issue.

Thank you for your assistance.

Mike