LDAP / Spam - Check order

Unanswered Question
Jun 15th, 2007

We found some records in the mail_logs with the following case:

A non-existing adress from a existing originator-domain sends a SPAM-Mail to a non-existing adress to our domain:
([email protected] -> [email protected])

Our C100 with activated LDAP accept query can't find the recipient '[email protected]' and send a 5.1.1 - Bad destination email address ('000', ['reject']) to '[email protected]'.

The mailserver at @somewhere.com makes the same, because '[email protected]" can't be found there.

Is it true that this will produce a mail-loop?

Can we change the check order in a way that the Spam-checking comes first and only if this check was negative, the LDAP accept query will have a look for the recipient?

What ist the reason, why this check order is by default
1. LDAP
2. Spam check
and not
1. Spam check
2. LDAP?

Addition: Would the changed order help to reduce "backscatter"? What are you doing against this form of mail?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Erich_ironport Sat, 06/16/2007 - 17:31

Here are a few reasons to do LDAP recipient acceptance validation first before SPAM checks.

1) When you do LDAP accept in the SMTP conversation it is done during the "RCPT TO" command and before the "DATA", so you can reject the message before you ever receive the message body. This terminates the unwanted message early in the SMTP connection, before any significant amount of data has been transmitted. Since this is before the "DATA" command and the message body has not been received you don't even have the option for spam analysis on the message at this point.

2) Due to the SMTP response of recipient rejection in the SMTP conversation as outlined above, you do not have to create an NDR message. The onus of creating the NDR is on the sending host. Moving LDAP recipient validation into the work queue after the message has been received, moves the onus of creating the NDRs for invalid recipients back to you and your systems.

3) LDAP validation is designed to be a high speed address validation and can be done quickly and with significantly less system load than fully spam analysis. Typically you always want to do the most efficient filtering processes first to limit the amount of messages which heavier load filtering is performed on later in the message flow. Remember the LDAP validation is based on a local LDAP record cache and does not have to query your LDAP host for every recipient.

Pat - I don't understand you question about a mail-loop?

You may want to look at the "Bounce Verification" also known as BATV (bounce address tag validation) technology on the IronPorts to prevent "backscatter".

Erich

Donald Nash Sat, 06/16/2007 - 22:07

Is it true that this will produce a mail-loop?

No. Non-delivery notices are not sent in response to other non-delivery notices, for precisely this reason. Non-delivery notices have a null envelope return address, <>, to make it impossible to reply to them.
Pat_ironport Sat, 06/16/2007 - 22:21

Thanks to both of you for your answers! For everyone who want to know some more details about bounce messages: Wiki

jbivens_ironport Thu, 06/21/2007 - 14:59

Pat,

Technically in a scenario like that it would be considered a double bounce, not a mail-loop. Basically the system bounces for the internal invalid recipient and once it determines the domain does not exist then it call it a double bounce.

The reasoning for the ordering of the mail flow comes to efficiency and performance, however Erich has outlined all the proper reasons for the way that IronPort engineers implemented the mail flow for AsyncOS.

Sincerely,

Jay Bivens
IronPort Systems

Actions

This Discussion