Messaging Gateway

I keep seeing this in my message audit log and its only for a few sender domains.

And the second line would say the "Abort Message".

How do I solve this issues? My users are unable to receive any emails from these sender domains.

So what this means is the timeout for them to transmit their message elapsed before they sent the end of message command. They most likely have throughput issues like a slow connection. 

You can adjust this timeout according to this document. If that doesn't work, you might want to do some throughput tests on your end to see what kind of speeds you are getting and if you have any internal network issues like a bad switch or NIC somewhere.


Title: 'Symantec Brightmail Gateway 8.0 message audit log shows abort message entries'
Document ID: 2007090713043654
> Web URL: http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2007090713043654?Open&seg=ent

I've followed the document, let's see what happens.

Doesn't work, could be a problem with the sender domain since it's the only domain having problems sending to us...?

Yeah, it could mean they are having network issues on their end. I have seen things like a NIC speed/duplex mis-matching the switch cause things like this.

Are you sure these are legitimate messages? It could also be spammers disconnecting due to either seeing that you're using a Brightmail device or unable to send their spam fast enough due to being delayed by our traffic shaping.

If you are still seeing "Message rejected by MTA" and "Abort message" entries in Audit Logs and you have alrready tried ALL the suggestions in the KB article that JDavis pointed to, then the issue could be due to a combination of a) the sending MTA issuing commands that do not conform to the RFC standard (indicated by "Message rejected by MTA" in Audit Logs) and b) timeout issues (indicated by "Abort message" in Audit Logs).

Additionally, you may also want to look at the following 2 KB articles to cover all the bases:

http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2009101313280854

http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2009101610162354

A packet capture of the SMTP converstaion is the best way to confirm the issue in situations like these.

Regards,

Adnan

Yep, there're legitimate messages from our customers.

I did hear that they had some system problems prior to this issue and after they fixed the "problem", they couldn't send mails to us anymore.

Ok thanks, I'll go through them

Hi enzo81,

Would you like to update us?

Thanks

Adnan

Hi AdnanH,

Both the KB do not apply to this situation, still seeing MTA rejected Message and Abort Message from this particular domain.

The IT department of the sending domain seem to be unwilling to divulge what they did to their email systems recently so there's no way to help them even if I wanted to.

Doesn't seem to be much we can do on the SBG.

Sorry to hear that you were not able to fix this issue. I definitely know what it's like when you are trying to troubleshoot an issue and the other party is unwilling to help!

Have you tried a packet capture? Here are the steps to run a packet capture on the appliance:

Capture Messages

1.    Enable support account from CLI
2.    Have your customer or sender ready to send in a few test messages
3.    Get the sender address, recipient address and the approx. time of sending for each email sent
4.    Type the following from the CLI:

tcpdump -s 0 -w /tmp/tcpdump/capture.cap -i any tcp port 25

5.    When the tcpdump starts you will see the message "WARNING: Promiscuous mode not supported on the "any" device" This is normal.
6.    When messages are sent, wait a few minutes then hit "CTRL+C" to end tcpdump
7.    Transfer the file /data/capture.cap from the appliance to your PC
8.    You can then analyse the capture file with a tool like Wireshark

Addition:     Capture smtp traffic only from/to a certain host

    tcpdump -s 0 -w /tmp/tcpdump/capture.cap -i any tcp port 25 and host 192.168.0.20

Thanks for the walkthrough. I'll try it out once I have a bit more spare time on my hands, pretty tied up with other stuff...
It's amazing how problems start popping up everywhere once a new year begins.

Hi enzo81,

Did you get a chance to see what's going on using the packet capture?

Regards,

Adnan

Hi enzo81,

Can you please provide an update?

Thanks

Adnan

Sorry for the late update, have been very tied up.

In any case I didn't have the chance to use packet capture but the problem has gone away.

Most probably the sender side has done some "fixes" on their end but they're not willing to reveal what happened or what they did.

Thanks.

Thanks for the update.

So the problem was in fact the sending side, if you did not change anything at your end.  This indicates that my initial assessment was correct when I said "the issue could be due to a combination of a) the sending MTA issuing commands that do not conform to the RFC standard (indicated by "Message rejected by MTA" in Audit Logs)".

Regards,

Adnan