Duplicate Internet email entries showing in Audit Log
Updated: 22 May 2010 | 9 comments
We are running SBG 8.02. In the Audit log, when I search for inbound internet emails such as gmail.com or hotmail.com I notice that the audit logs show 2 entries for 1 email. And it shows 2 actions that the appliance applied. I redacted our domain address, hence the ------.com. The result is the emails do get delivered which is fine but whats up with the second entry that says "Message rejected by MTA"?
Here's a couple exampes:
Discussion Filed Under:
Comments
So I found this document that
So I found this document that discusses Aliasing,
However, the odd thing is that the mail is showing "None" for the address on the second line. I can't say as I know what is happening there, but are you doing any aliasing that might be the culprit?
Let me know.
Thanks!
I checked Aliasing and it is not turned on...
Hi there, What's your
Hi there,
What's your environment setup? Is the SBG Appliance at the gateway ? Are you using LDAP ?
Thank you,
Marco Bicca
The Scanner appliance sits
The Scanner appliance sits in the DMZ as the gateway and the Control Center sits in our lan. We are using LDAP. No issues with LDAP in our logs...
Hi There.. Did you checked in
Hi There..
Did you checked in the audit logs for both same mail coming from same source address ?
Did your brightmail is enable with IP Reputation service ?
awaiting for reply !!
You said you are using
You said you are using LDAP Right? Are you seeing recipients being rewritten in the Audit Log? Can you actually post a screenshot of exactly what you see in the Message Audit Log screen results?
Here's a pic of our audit logs.
so you can see with the pic
so you can see with the pic above, the appliance thinks its getting 2 emails and behaves differently on the second one...Never saw this before we upgraded to ver 8.
Need help! :)
Stephen
Hi, I've seen a similar issue
Hi,
I've seen a similar issue in the past and is documented in the following KB article:
service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2009101313280854
I remember there was an upstream device blocking the inbound SMTPO EHLO command forcing the remote MTA to fail back to HELO (apologies if this is too technical).
Hope it helps. Let me know.
Regards,
Federico
Would you like to reply?
Login or Register to post your comment.