mail.current - entry / Same lines repeating again and again

Pat_ironport · ‎04-30-2008

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'])

Could some kind of loop be the source of the huge amount of such entries? Do I have any chance to stop this useless traffic?

Donald Glynn · ‎04-30-2008

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'])

Could some kind of loop be the source of the huge amount of such entries? Do I have any chance to stop this useless traffic?

Pat_ironport · ‎04-30-2008

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.
Our IronPort-system doesn't have such a name. For sure, we don't have a IronPort-systemname called 'bounce.ironport1@ourcompany.com'

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.

Donald Nash · ‎05-01-2008

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.

Pat_ironport · ‎05-02-2008

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.

Could you please tell me the necessary steps to move the LDAP verification to the SMTP conversation?
Are there any disadvantages I should know?

Donald Nash · ‎05-02-2008

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.

Pat_ironport · ‎05-02-2008

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]

Pat_ironport · ‎05-03-2008

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 1983702

I 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)

And again some minutes later:
Since I changed the LDAP query from Work Queue to SMTP, our initial problem with arizonaprint is gone! FANTASTIC!!

The last entry we found in the mail.current is one hour back:

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

Donald Nash · ‎05-03-2008

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.

Pat_ironport · ‎05-05-2008

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?

Donald Nash · ‎05-05-2008

WOW! Today we have detected that the overall-value on the 'Incoming Mail Graph' was reduced by more then 50%!

Sounds like you had a mail loop. They sent you a message which you bounced back to them, which they tried to forward back to you, which you bounced back to them, etc. Doing recipient validation during the SMTP conversation broke the loop because your server rejected the message outright rather than accepting it and bouncing it later.

BTW: Why should someone choose our previous configuration with the check in 'Work Queue'? Just because auf DHA?

DHA is part of it. There are also reliability and performance concerns, since SMTP becomes dependent on LDAP when you do recipient validation during the SMTP conversation.

Bart_ironport · ‎05-05-2008

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.

Donald Nash · ‎05-05-2008

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.