Delivery Failure Reports and IronPort Spam Quarantine Notifi

Unanswered Question
Aug 18th, 2008
User Badges:

Hello!

I have a mail-in database which is primarily used to recieved weekly and monthly reports genereted from our 2 C350s. However, the mail-in database is also "spammed" by delivery failure reports which cannot be delivered because the recieving user does not exist. I get the following failures:

Delivery Failure Report
Your document: IronPort Spam Quarantine Notification
was not delivered to: [email protected]
because: 5.1.0 - Unknown address error 550-'[email protected]... No such user' (delivery attempts: 0)

Does anyone know what I need to configure in order to possibly drop these e-mails instead?

Thx in advance!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
kluu_ironport Tue, 08/19/2008 - 00:27
User Badges:

If there are recipient addresses that you don't want to have receive the digest quarantine notification, why don't you create a new incoming mail policy where the recipient is a member of this new policy. Disable anti-spam/anti-virus for this new policy and put in a content filter that doesn't have a condition and just drops the mail.

Here are the steps:

1. Create a new incoming mail policy, i.e "Drop_Recipients"
2. Add the recipient email address that you don't want to have receive the quarantine digest notification as a member of this new policy.
3. Disable anti-spam and anti-virus for this new policy.
4. Create a incoming content filter that does not have any conditions. The only action is a drop().
5. Then able this incoming content filter on this new policy.


Let me know if this is what you're looking for or if there is a reason why this doesn't address your issue.

By the way, the purpose of the above steps is so that the messages for this recipient doesn't get quarantined.


Hello!

I have a mail-in database which is primarily used to recieved weekly and monthly reports genereted from our 2 C350s. However, the mail-in database is also "spammed" by delivery failure reports which cannot be delivered because the recieving user does not exist. I get the following failures:

Delivery Failure Report
Your document: IronPort Spam Quarantine Notification
was not delivered to: [email protected]
because: 5.1.0 - Unknown address error [email protected].. No such user' (delivery attempts: 0)

Does anyone know what I need to configure in order to possibly drop these e-mails instead?

Thx in advance!
ironmagic_ironport Thu, 08/28/2008 - 07:32
User Badges:

I apologize for the late reply. Im not really sure if this is the right way to do it. Let me further explain my issue.

I have a alert recipent which i created to mainly recieve weekly reports containing e-mail statistics, hardware alerts, system alerts etc. This same alert recipent seems to be the one sending the suspected spam quarantine notifications, which are sent to email adresses within our domain. However, these users dont exist, so they bounce back. For example, suspected mail is recieved by ironport and a mail notification (spam notification) about this is then delivered to user [email protected], however, [email protected] does not exist. So this email(spam notification) bounces back to my alert recipent address. But i feel that the suspected spam shouldnt make it that far, because when it first hits Ironport an LDAP query should be sent? if the user does not exist, there is no need to send a suspected spam notification to a user does not exist. Ironport is also configured to send an ldap query to our mail server to check if the user exists, but im not sure if it applys to all sorts of email, spam or not. Any suggestions?

kluu_ironport Thu, 08/28/2008 - 07:42
User Badges:

Sounds like LDAP Accept Query is not working correctly, because if it was working correctly, those invalid recipients would be dropped before the anti-spam scanning occurs.

Generally, if a non-existent recipient email (i.e. [email protected]) gets a spam notification, that must mean somehow it passed the ldap accept query or ldap is not enabled.

You can test if ldap is working correctly or not by going to "System Administration > Trace"

For the IP, use "1.2.3.4"
Host: test.com

Envelope Sender: [email protected]
Envelope Recipient: [email protected] or another recipient email that is not suppose to be valid.

Body of message:

Subject: test 123

The result you should be getting is that the message is dropped or bounced if the "envelope recipient" is invalid. If it gets through the whole scanning part and then delivered, then ldap is not working correctly since the recipient is fake.

ironmagic_ironport Thu, 08/28/2008 - 09:59
User Badges:

These are the results of my "fake" trace. Seems like the RAT table rejects it, but should this occur before or after the LDAP query?

Trace Results
Host Access Table Processing (Listener: IncomingMail)
Matched On: sbrs[none]
Sender Group: UNKNOWN
Named Policy: CONTROLLED
Connection Behavior: ACCEPT
Fully Qualified Domain Name:
SenderBase Network Owner ID: N/A
SenderBase Reputation Score: N/A
Policy Parameters:
Max. Messages Per Connection: 5
Max. Recipients Per Message: 25
Max. Message Size: 50M
Max. Concurrent Connection From a Single IP: 5
Use TLS: No Default
Accept Untagged bounces: No
Max. Recipients Per Hour: 30
Use SenderBase: Yes Default
Use Spam Detection: Yes Default
Use Virus Detection: Yes Default
Envelope Sender Processing
Envelope Sender: [email protected]
Default Domain Processing: No Change
Envelope Sender Verification: Resolved test.com successfully
Envelope Recipient Processing
Envelope Recipient: [email protected]
Default Domain Processing: No Change
Domain Map Processing: No Change
Recipient Access Table Processing: Behavior: REJECT Matched On: [email protected]
Alias Expansion: No Change

ironmagic_ironport Thu, 08/28/2008 - 10:23
User Badges:

Think i found what was wrong. Under my listener settings - LDAP queries (network > listener) , the "accept query" option was set to none, instead of the server profile i had created. I have set the "accept query" option to the profile I had created and now I have the option to select bounce or drop. Which option is preferred from a security perspective? Is it possible for spammers to exploit the fact that if I choose to bounce it, it confirms that something is there listening and they might keep on trying to with other adresses, or some other way? Or should i just drop it? If i do choose to drop it, then legitimate e-mails where the sender by accident mispelled an email adress wouldnt get a notification that the e-mail wasn't delivered, is this correct? Please advise.

kluu_ironport Thu, 08/28/2008 - 15:45
User Badges:


 .... and now I have the option to select bounce or drop. Which option is preferred from a security perspective? 


For the most part, companies set it to "drop" invalid recipients. If you set it to "bounce", you may inadvertently start spamming innocent folks. This is because when you're bouncing back to the sender domains of those fake recipient emails, it could be going back to legitimate domains, since the spammers probably aren't going to use their own addresses.

Also, you have look up "directory harvest" attack in the AsyncOS User Guide to see how LDAP tries to fend off DHAP(Directory Harvest Attack Prevention) attacks.

 If i do choose to drop it, then legitimate e-mails where the sender by accident mispelled an email adress wouldnt get a notification that the e-mail wasn't delivered, is this correct?


That is correct. If you set it to drop, you would drop for folks who mistype the recipient's email address. That would be something you need to weigh in when deciding which to use.

If you want to play it safe, then I would bounce but keep in mind you would be sending a lot of bounce messages back to the sender domains who didn't send those mail in the first place. Drop invalid recipients and you reduce the load on your mailserver and the IronPort appliance, but don't give a break to folks who "fat finger" a recipient's email address.

Maybe some other customers can chime in on what best works for their mail flow.
ironmagic_ironport Fri, 08/29/2008 - 12:49
User Badges:

Well, we decided to go with the bounce option. Atleast for now :)

However, my next problem indicates that our LDAP query is incorrect, because whenever I edit my listeners and change them so they use the LDAP profile I have setup, (Listeners >> I click on my listener >> LDAP queries >> Accept ) , mail to our mailing lists are bounced, which is not quite the purpose. Im not very good at designing LDAP queries, but it basically looks like this now: (mail={a}) . Unfortunately, it doesn't seem to match all addresses, so obviously it needs to be rewritten. Any suggestions/tips? We are using Lotus Domino.

Thanks in advance.

SPAMHater_ironport Fri, 08/29/2008 - 14:20
User Badges:


Well, we decided to go with the bounce option. Atleast for now :)

However, my next problem indicates that our LDAP query is incorrect, because whenever I edit my listeners and change them so they use the LDAP profile I have setup, (Listeners >> I click on my listener >> LDAP queries >> Accept ) , mail to our mailing lists are bounced, which is not quite the purpose. Im not very good at designing LDAP queries, but it basically looks like this now: (mail={a}) . Unfortunately, it doesn't seem to match all addresses, so obviously it needs to be rewritten. Any suggestions/tips? We are using Lotus Domino.

Thanks in advance.


Which part of the address are you trying to query for? If you are trying to get the whole SMTP address the "mail" attribute would be the correct query. Has your schema been modified in any way, are the SMTP addresses populated correctly in your Domino directory? Try using the free Softerra LDAP Browser to take a look to make sure you have the right attributes in your schema etc.
ironmagic_ironport Tue, 10/14/2008 - 15:28
User Badges:

...Sorry for the very late reply, I have been extremely busy and unfortunately not been able to proritize this issue..

However, I used the softerra browser and It seems to me that I have the correct attributes in my schema.

I have modified my LDAP query to match even more addresses, and what seem to be left is addresses with and _ (underscore), for example, when I test my query for [email protected] I would get:

Success — Action: drop or bounce (depending on listener settings)
Reason: no matching LDAP record was found

If I try an address without an underscore, it passes the test.

Any ideas on how to create an LDAP query that somehow accepts mail attributes containing underscores?

kluu_ironport Tue, 10/14/2008 - 17:48
User Badges:

Can you paste in the LDAP Accept Query string that you are using?

Also, enable the ldap debug logs and run through two tests.

1. [email protected]

2. [email protected]

and then paste in the ldap debug log results.


The snippet that you provided,

Success — Action: drop or bounce (depending on listener settings)
Reason: no matching LDAP record was found

appears to be a successful query that just resulted in the record not being there. I'd be interested in the ldap debug results and your accept query though.


...Sorry for the very late reply, I have been extremely busy and unfortunately not been able to proritize this issue..

However, I used the softerra browser and It seems to me that I have the correct attributes in my schema.

I have modified my LDAP query to match even more addresses, and what seem to be left is addresses with and _ (underscore), for example, when I test my query for [email protected] I would get:

Success — Action: drop or bounce (depending on listener settings)
Reason: no matching LDAP record was found

If I try an address without an underscore, it passes the test.

Any ideas on how to create an LDAP query that somehow accepts mail attributes containing underscores?
ironmagic_ironport Tue, 10/14/2008 - 19:05
User Badges:

Here is the LDAP query I am using at the moment. Unfortunately, I'm not sure that it is correct and appreciate all the help I can get to construct a correct one, or even maybe be tipped about some good LDAP resources where I can learn more about this topic.

Anyway, (|(mail={a})(uid={a})) is the query. As mentioned before, an address like [email protected] would generate "no matching LDAP record was found", even though it does exist, whilst [email protected] would not.


Tue Oct 14 19:41:06 2008 Info: Begin Logfile
Tue Oct 14 19:41:06 2008 Info: Version: 6.3.5-009 SN: xxxxxxxxxx-xxxxxxx
Tue Oct 14 19:41:06 2008 Info: Time offset from UTC: 7200 seconds
Tue Oct 14 19:42:11 2008 Debug: LDAP: Clearing LDAP server-group "xxxxxxxx" cache
Tue Oct 14 19:42:11 2008 Debug: LDAP: Clearing LDAP server-group "xxxxxxxx" cache
Tue Oct 14 19:42:11 2008 Debug: LDAP: xxxxxxxx:xxx.xxx.xxx.xxx(xxx.xxx.xxx.xxx:389) (1) connecting to server
Tue Oct 14 19:42:11 2008 Debug: LDAP: xxxxxxxx:xxx.xxx.xxx.xxx(xxx.xxx.xxx.xxx:389) (1) connected to server
Tue Oct 14 19:42:12 2008 Debug: LDAP: (accept) Query (|([email protected])([email protected])) to server xxxxxxxx (xxx.xxx.xxx.xxx:389)
Tue Oct 14 19:42:12 2008 Debug: LDAP: (accept) Query (|([email protected])([email protected])) lookup success, (xxx.xxx.xxx.xxx:389) returned 0 results
Tue Oct 14 19:42:17 2008 Debug: LDAP: xxxxxxxx:xxx.xxx.xxx.xxx(xxx.xxx.xxx.xxx:389) (1) Connection interrupted (writer)
Tue Oct 14 19:46:15 2008 Debug: LDAP: Clearing LDAP server-group "xxxxxxxx" cache
Tue Oct 14 19:46:15 2008 Debug: LDAP: Clearing LDAP server-group "xxxxxxxx" cache
Tue Oct 14 19:46:15 2008 Debug: LDAP: xxxxxxxx:xxx.xxx.xxx.xxx(xxx.xxx.xxx.xxx:389) (1) connecting to server
Tue Oct 14 19:46:15 2008 Debug: LDAP: xxxxxxxx:xxx.xxx.xxx.xxx(xxx.xxx.xxx.xxx:389) (1) connected to server
Tue Oct 14 19:46:16 2008 Debug: LDAP: (accept) Query (|([email protected])([email protected])) to server xxxxxxxx (xxx.xxx.xxx.xxx:389)
Tue Oct 14 19:46:16 2008 Debug: LDAP: (accept) Query (|([email protected])([email protected])) lookup success, (xxx.xxx.xxx.xxx:389) returned 1 results
Tue Oct 14 19:46:21 2008 Debug: LDAP: xxxxxxxx:xxx.xxx.xxx.xxx(xxx.xxx.xxx.xxx:389) (1) Connection interrupted (writer)
kluu_ironport Tue, 10/14/2008 - 21:13
User Badges:

Tokens:
You can use the following tokens in your LDAP queries:
• {a} [email protected]
• {d} domainname
• {g} groupname
• {u} username
• {f} MAIL FROM: address
Note — The {f} token is valid in acceptance queries only.


Instead of this

(|(mail={a})(uid={a}))

Try this:

(|(mail={a})(uid={u}))

It may be that the username portion of "[email protected]" is set in the uid as this:

uid=john_joe


-Kevin


Here is the LDAP query I am using at the moment. Unfortunately, I'm not sure that it is correct and appreciate all the help I can get to construct a correct one, or even maybe be tipped about some good LDAP resources where I can learn more about this topic.

Anyway, (|(mail={a})(uid={a})) is the query. As mentioned before, an address like [email protected] would generate "no matching LDAP record was found", even though it does exist, whilst [email protected] would not.

ironmagic_ironport Wed, 10/15/2008 - 07:24
User Badges:

Unfortunately your query did not work, I have tried it before, and its because its not in the uid attribute, but in the mail attribute, I have confirmed this with the softerra browser.

Any more tips on how to solve this? :(

kluu_ironport Wed, 10/15/2008 - 15:31
User Badges:

If you don't mind, can you provide the LDIF export for [email protected]? In Softerra, if you right click on the user, there is an option for to a LDIF export.

Unfortunately your query did not work, I have tried it before, and its because its not in the uid attribute, but in the mail attribute, I have confirmed this with the softerra browser.

Any more tips on how to solve this? :(
ironmagic_ironport Wed, 10/15/2008 - 20:28
User Badges:

This is basically as much as I can present, I have to obscure certain details, however the format is the same, the X:s just replace the actually non-obscured data.


#-------------------------------------------------------------------------------
# This file has been generated on 10.15.2008 at 16:51 from xxx.xxx.xxx.xxx:389
# by Softerra LDAP Browser 2.6 (http://www.ldapbrowser.com)
#-------------------------------------------------------------------------------
version: 1
dn: CN=XXX XX XXXXXXXXXX,OU=XXX_XXXXXXX_XXXXXX,OU=XXX_XXXXXXXXX,O=XXXXXXX
cn: XXX XX XXXXXXXXXX
mail: [email protected]
originalmodtime: 20060XXX115359Z
grouptype: 0
description:: QWxsYSBww6UgVk46cyByZWRha3Rpb24gKyBOeWhldHNwb29sZW4=
availablefordirsync: 1
objectclass: dominoGroup
objectclass: groupOfNames
objectclass: top
grouptitle: 0
member:: Q049QmlyZ2l0dGEgTG9yZW50enNvbixPVT00MDVfVsOkcm5hbW9fTnloZXRlcixPVT00MDFfSGFs
bHByZXNzZW4sTz1IZXJlbmNv
member:: Q049Q2hyaXN0ZXIgR2FsbG5lYnksT1U9NDA1X1bDpHJuYW1vX055aGV0ZXIsT1U9NDAxX0hhbGxw
cmVzc2VuLE89SGVyZW5jbw==
member:: Q049Q2hyaXN0ZXIgTm9yZG1hcmssT1U9NDA1X1bDpHJuYW1vX055aGV0ZXIsT1U9NDAxX0hhbGxw
cmVzc2VuLE89SGVyZW5jbw==
member:: Q049Q2hyaXN0ZXIgV2lkYWhsLE9VPTQwNV9Ww6RybmFtb19OeWhldGVyLE9VPTQwMV9IYWxscHJl
c3NlbixPPUhlcmVuY28=
member:: Q049Q2hyaXN0aWFuIEFuZGVyc3Nzb24sT1U9NDA1X1bDpHJuYW1vX055aGV0ZXIsT1U9NDAxX0hh
bGxwcmVzc2VuLE89SGVyZW5jbw==
kluu_ironport Thu, 10/16/2008 - 07:54
User Badges:
m00hshu_ironport Wed, 11/19/2008 - 11:05
User Badges:

I suspect you've found a solution, but I thought I'd share my experience with the forum, in case anyone else ran into the same issue :)

We use (proxyAddresses=smtp:{a}) as our query string.
That should also contain your "primary" mail smtp account AND all your aliases, so it would be the safest one to go for :)

steven_geerts Sun, 11/23/2008 - 15:32
User Badges:

HI,

The query string (proxyAddresses=smtp:{a}) works perfectly for Exchange. The proxyAddresses LDAP field contains all email addresses that belong to an Exchange object. Since Exchange supports more protocols than SMTP, this address is prefixed with the protocol identifier (smtp: for SMTP, x400: for x400 addresses etc. ).

Since this topic is about Domino I think querying for MS attributes makes no sense.
I did some Googling on the subject and found a related topic on the Symantec Brightmail Forum :twisted:


Setup taht worked for me:

Recipient Validation Query : (|(mail=%s)(uid=%s))


- Enable distribution list expansion

- Preserve Recipient Addresses


Both enabled.


If you look at the LDAP query it's similar as the one you use (expect that Brightmail uses %s where Ironport uses {a})
The interesting things might be the two additional remarks. I guess those are Domino settings. Since you have troubles with your distribution lists I think the "enable Distribution List Expansion" option might solve your problem.

Another interesting link": the IBM knowledgebase explains how Domino is "building" its SMTP addresses and how to configure LDAP on Domino:
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/topic/com.ibm.help...

Good luck!
Steven

PS: since I need to connect a Domino system to my LDAP system soon, I'm very interested in the final solution.


Actions

This Discussion