04-30-2008 09:17 AM
Just to understand the log-entries better:
I have many tousends of this entries in the mail.current-logfile (with exactly this sender):
Wed Apr 30 09:46:19 2008 Info: Start MID 2500703 ICID 1921372
Wed Apr 30 09:46:19 2008 Info: MID 2500703 ICID 1921372 From: sales@arizonaprint.com
Wed Apr 30 09:46:19 2008 Info: MID 2500703 ICID 1921372 RID 0 To: bounce.ironport1@ourcompany.com
Wed Apr 30 09:46:19 2008 Info: MID 2500703 Message-ID ' 200804300746.m3U7kIS3004543@host.hostadomainname.com '
Wed Apr 30 09:46:19 2008 Info: MID 2500703 Subject 'MESSAGE NOT DELIVERED: Delivery Status Notification (Failure)'
Wed Apr 30 09:46:19 2008 Info: MID 2500703 ready 1184 bytes from sales@arizonaprint.com
Wed Apr 30 09:46:19 2008 Info: LDAP: Bounce query accept MID 2500703 RID 0 address bounce.ironport1@ourcompany.com
Wed Apr 30 09:46:19 2008 Info: Bounced: DCID 0 MID 2500703 to RID 0 - Bounced by destination server with response: 5.1.1 - Bad destination email address ('000', ['reject'])
04-30-2008 02:24 PM
Pat I'm going to assume that "bounce.ironport1@ourcompany.com" is the host name of the system. The MTA attempting to send the bounce back is replying to another bounce message. When the message gets to you the LDAP is not accepting the RCPT TO: because that name does not exist in the LDAP.
The original bounce needs to be researched to locate it and stop it. This is what started the bounce loop.
[quoteJust to understand the log-entries better:
I have many tousends of this entries in the mail.current-logfile (with exactly this sender):
Wed Apr 30 09:46:19 2008 Info: Start MID 2500703 ICID 1921372
Wed Apr 30 09:46:19 2008 Info: MID 2500703 ICID 1921372 From: sales@arizonaprint.com
Wed Apr 30 09:46:19 2008 Info: MID 2500703 ICID 1921372 RID 0 To: bounce.ironport1@ourcompany.com
Wed Apr 30 09:46:19 2008 Info: MID 2500703 Message-ID ' 200804300746.m3U7kIS3004543@host.hostadomainname.com '
Wed Apr 30 09:46:19 2008 Info: MID 2500703 Subject 'MESSAGE NOT DELIVERED: Delivery Status Notification (Failure)'
Wed Apr 30 09:46:19 2008 Info: MID 2500703 ready 1184 bytes from sales@arizonaprint.com
Wed Apr 30 09:46:19 2008 Info: LDAP: Bounce query accept MID 2500703 RID 0 address bounce.ironport1@ourcompany.com
Wed Apr 30 09:46:19 2008 Info: Bounced: DCID 0 MID 2500703 to RID 0 - Bounced by destination server with response: 5.1.1 - Bad destination email address ('000', ['reject'])
04-30-2008 03:51 PM
Pat I'm going to assume that "bounce.ironport1@ourcompany.com" is the host name of the system.I don't think so - The adress looks like a ordinary, but not existing email-adress.
The original bounce needs to be researched to locate it and stop it. This is what started the bounce loop.I agree. Could you please give me some advice how I can do that? My experience isn't sufficient for this research-process.
05-01-2008 07:27 PM
Pat,
It looks like you're doing LDAP verification within the work queue rather than during the SMTP conversation. Is that correct? If so, that means your appliance has to accept the message, then bounce it when it can't be delivered. Moving LDAP verification to the SMTP conversation should break the loop because your appliance would reject the message entirely.
05-02-2008 09:45 AM
It looks like you're doing LDAP verification within the work queue rather than during the SMTP conversation. Is that correct?Hmm, to be honest: I don't know. :oops: How can I verify this?
Moving LDAP verification to the SMTP conversation should break the loop because your appliance would reject the message entirely.
05-02-2008 02:09 PM
Use the GUI to check the settings for your listener. There is an "LDAP Queries" section in the listener settings. There is a pair of radio buttons to select between "Work Queue" and "SMTP Conversation". Check the Advanced User Guide for more details. There is an entire chapter on LDAP there.
The disadvantage is that you're more open to a directory harvest attack because attackers get instant feedback about whether a recipient is valid. But AsyncOS has a DHA prevention feature that you can turn on to thwart this.
To me, the advantage outweighs the disadvantage. You don't accept mail that you can't deliver, so you avoid backscatter. You also avoid loops like the one that's hurting you here.
05-02-2008 03:39 PM
Thank you very much for your help and explanation, dlnash! :)
[size=9:a2254a8df1](I'm already in the weekend and will try the configuration-change next monday!)[/size:a2254a8df1]
05-03-2008 12:37 PM
Now, I have changed the LDAP Querie-part from 'Work Queue' to 'SMTP Conversation' for the 'IncomingMail'-Listener.
(Network, Listeners).
And you are right: I still get mails "...User unknown..." if I try to send a mail from my webmail to a non-existent recipient in our company. Great!
But then, I have some additional questions:
What should I set for
'Directory Harvest Attack Prevention (DHAP)'?
Should I start with 'Unlimited'? Or what do you suggest as practical values?
Should I set the 'Max. Invalid Recipients Per Hour' to the default '5'?
What do you have set for:
'Drop Connection if DHAP threshold is Reached within an SMTP Conversation'?
Thanks again for your patience and very appreciated help!
Some minutes later:
I tried to set the value for ''Max. Invalid Recipients Per Hour' to 5 and got very fast a warn-email and an entry in the logfile errors.current:
Sat May 3 13:50:08 2008 Warning: Dropping connection due to potential Directory Harvest Attack from host=('111.222.111.123', None), dhap_limit=5, sender_group=ALL, listener=IncomingMail, reverse_dns=111.222.111.123, ICID 1983702I think, that value doesn't work in our configuration to the ASP. :wink: I reverted this value back to 'Unlimited' until I get some advices from professionals like you 8)
Sat May 3 13:11:18 2008 Info: Start MID 2619316 ICID 1983597
Sat May 3 13:11:18 2008 Info: MID 2619316 ICID 1983597 From: sales@arizonaprint.com
Sat May 3 13:11:18 2008 Info: MID 2619316 ICID 1983597 To: bounce.ironport1@ourcompany.com Rejected by LDAPACCEPT
Sat May 3 13:11:18 2008 Info: Message aborted MID 2619316 Receiving aborted by sender
Sat May 3 13:11:18 2008 Info: Message finished MID 2619316 aborted
05-03-2008 03:12 PM
I'm glad the LDAP change worked for you. I wouldn't worry about DHAP for the moment. The fact that your ASP is causing problems needs to be fixed. Once they quit trying to send you those bogus messages, you can turn DHAP back on. Just take the recommended default values, they're a good place to start.
05-05-2008 03:38 PM
WOW! Today we have detected that the overall-value on the 'Incoming Mail Graph' was reduced by more then 50%!
Your advice to move the LDAP Querie from 'Work Queue' to 'SMTP Conversation' seems to be veeeeeery effectiv. No more 'arizonaprint' since Saturday. :wink:
Thank you very much, dnlash, for that hint. :D
BTW: Why should someone choose our previous configuration with the check in 'Work Queue'? Just because auf DHA?
05-05-2008 04:37 PM
WOW! Today we have detected that the overall-value on the 'Incoming Mail Graph' was reduced by more then 50%!
BTW: Why should someone choose our previous configuration with the check in 'Work Queue'? Just because auf DHA?
05-05-2008 04:39 PM
That is indeed the most common reason. But I prefer doing the check during conversation because it also means we don't have to send out bounces for those messages, saving us from a lot of possible problems.
I pretty much always use in-conversation checking. There might be a few where its done in the work queue but thats just because it was (is?) the default and we forgot to change it - almost never intentionally.
Imho, the risk of a DHA is nothing compared to the advantages you get from rejecting invalid recipients as soon as possible.
05-05-2008 04:51 PM
Bart: Yes, I agree. As I said above, IMO the advantages outweigh the disadvantages. Just the reduction of blowback alone is a big deal, especially since so many people penalize for it. And the disadvantages can be dealt with: A carefully planned and maintained LDAP infrastructure can greatly reduce the risk of LDAP-related SMTP problems; and IronPort's DHAP features make DHAs much less of a problem. You still have an overall more complex system to take care of, but welcome to the 21st Century. Hard problems tend to make for hard solutions.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide