Hello Yasin,

The "Abort Message" alert is caused by something delaying or stopping the mail traffic during the message transaction.

The first thing I would take a look at would be the Session Timeout. Since some mail servers may be a little slower on sending of the message this can happen. Go to the Hosts configuration on the Administration tab, then go to the SMTP section and to the advanced settings at the bottom. You will see the session timeout under the Inbound SMTP Configuration.

Try to up this and see if it helps.

Thanks!

Tom

Hello Tom,

thank you for help

but

my problem is continue :(

defult session time out 30 sec.

new value 30 min.

Hello again Yassin,

The other thing that could be causing an issue would be firewall settings. Commonly, filtering within the firewall can cause early aborting of messages.

Please take a look at the following document and see if this helps at all:

Title: 'Message audit log shows a disposition of None or Aborted'

Also, are you using LDAP? If so do you have "Drop Invalid Recipients" in use? This can also give you the message in the audit logs because it drops the message at the recipient command.

By the way, I would go with a smaller interval than 30 minutes. Maybe bump it to 60 seconds and work with it from there. You could have other issues if you make the time out too long.

Thanks!

Tom

I would probably look to debug the MTA and examine the MTA logs in this situation as well.  They will probably give a bit better indication as to what the problem could be.

Kevin

i faced a similar issue and i found that the downstream server were having a mail scanning software which after removing the software it works fine with me .

Where is mta log

Hello,

Sorry about the late response. The MTA logs can be pulled from the user interface on the logs page. Change "Log Type" to MTA Logs. This would be the easiest way to get them. You can also pull them from the file structure using something like WinSCP, but you would most likely need support interaction for this.

Which by the way, you may need to call support at this point with the issues you seem to be having.

Thanks!

Tom

Recently we got some solution for this issue from symantec support, i can help you to solve this abort issue.

kindly update what version you are using now on your appliance.

Hi Mikee,

is there any solution to this issue?  We have the same problem oure  Symantec Brightmail 8.0.0-24 

Thamks
Reejith .

Hi Reejith,

This error message isn't an indication of a specific problem, or that there is an issue, there are many different reasons why you could see this message so to find out exactly what's going on further troubleshooting needs to be done.  Are you seeing this issue from only particular domains, all domains? Is it happening to all messages, only large messages?  

Opening a case with Support is really probably the best way to get help to find out what's going on.

Kevin

We have just make a finding about thos message getting aborted.

I have looked at the column "accepted from" and tested those public IP addresses agaisnt Symantec IP reputation lookup. I've tested more that 20 now and they all got the same result :

The IP address XXX.XXX.XXX.XXX was found to have a negative reputation. Reasons for this assessment include:
The host appears to be sending unauthorized email.
To request that this IP address reputation be cleared, check the applicable boxes below and click Investigate.
you can check for yourself and go directly to the website "http://ipremoval.sms.symantec.com/lookup/"

so the problem is that those mail are sent from zombies machine or suspected spammers. you need to check whether this is legitimate email or not.
if those email are legitimate you will have to modify the rule. to do it you will need to go to the web interface of your appliance.

in verion 8 you will need to go to "reputation" tab then you need to check "third party bad sender" and "symantec global reputation list"

both have by default the reject action, you may want to change that action or disable the feature.

After disabling symantec global reputation system then disable the "connection classification"

if this rule is disabled those message will continue to be filtered by the antispam engine and will be deleted if it is really a Spam.

Mikee, Kevin

Thanks for your replies. We see the issue mostly from hotmail.com, live.com and msn.com . There are some strange observations.
 
Almost 99 % of mails from hotmail are aborted. But some mails from a particular hotmail id is always (33/33 =100%) passed through,  regardless of their content ( we tried content less, and text content and even images ). The sender IPs for the ones that pass always are from the segment 65.54.246.X  The ones that are rejected come from various different 65.55.x.x  and 65.54.X.X  ranges.  Occasionally mails from gmail and other domains also get aborted, say around 50 percent (the percentage seems to be going up now).

Random tests of the aborted sender ips show that they don't have any negative reputation. The message queues are always less than 100 mails, mostly having invalid recipients etc. The appliance runs on 3G RAM and has 4 CPU's.

We have a ticket with symantec but if someone here has any ideas, we'd like to try those too.
 

I imagine Support are probably looking for debugged MTA logs and probably BMserver logs from you capturing messages coming in from these domains.  These should probably give some good help as to what's happening.  I guess the one thing to remember is if you aren't having problems getting messages from a lot of other domains this mightn't actually be your issue...

Kevin

Hey Hi,

I need your help to clear my doubt related to SMTP communication,

According to analyses TCPDump logs we got that in communication between Message body we getting error "TCP Retransmission" that means packets are getting droped some where and my appliance try to retransmission .

MTA logs "error code 421 service time out", and through TCP Dump it show "TCP Retransmission" for message body.

But my query is, SMTP is TCP base communication protocols so whenever each SMTP command sent from sender to receiver host, Sender always waits for ACK to send new command.

In "TCP Retransmission" message body. even if we lost the communication between message body for any reason, So Sender domain always keep message copy till it get delivered successfully with ACK received from receiver Domain or it will be retried to deliver that message.

How can we lost mails completely in this case, why mails are not retried to send, Why user needs to resend the mail.

pls clear my doubt

I ran in to a similar issue with one of my customers. I would suggest that you go through the following document in order to address the issue:

Title: 'Message audit log shows Abort Message entries'
Document ID: 2007090713043654
> Web URL: http://service1.symantec.com/SUPPORT/ent-gate.nsf/...

There have been some updates to the document since my last case. I believe one of the most important things in this case was setting the message time-out to 5 minutes. This is only suggested for version 8 as our previous MTA didn't handle the high time outs as well. But please be sure to follow all the steps in the document for your version.

I may not be understanding your question so if you could clarify what exactly it is you are asking it would be appreciated.

Thanks!

We ran into the same issue.  We could see that the SMTP from and to worked but when the data prompt appeared, the connection was aborted.

Our resolution was in the MTU (Maximum Transmission Unit).  Ours was set at 512, thus anything larger was getting aborted.  It only affected certain domains that were sending.  Setting to 1500 solved the problem completely.

Administration -> Hosts > Configuration -> Edit Host -> Ethernet -> Maximum Transmission Unit

Best regards,
Alex

Alex, thanks for sharing the information.

Please note that by default, the MTU is set to 1500; you can check it by running the ifconfig command from CLI:

vm-sflabga> ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0C:29:38:3F:77 
          inet addr:10.160.248.101  Bcast:10.160.248.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

So you must have manually changed it to 512.  May I ask why did you change it to 512?

Regards,

Adnan