Action taken: Abort message

[Migration User]

Hi.

I have a strange problem with inbound mail. I can see a lot of messages insight of Message Audit Logs with "Abort message". All messages came from different senders via different SMTP servers, to different recipients. The one thing that is similar to all messages is that they do not have a subject line (Message Audit Logs shows that they do not have it).

Is there any configuration that can be checked or set to solve this bug? Is it bug or misconfiguration? I do not found any settings that can be responsoble for that action...

And yes - Message Audit Logs did not says anything more about this kind of messages. I can not understand what is wrong, there is no any match with any filtering policy. Verdict is just "none"...




I forget to add. There is one message that oroginally have been aborted, but later, then it comes _with_ subject defined, it have been receaved without problems! So there is somthing wrong with subject processing, but I just can't found that. :(

Message Edited by beastie on 06-09-2008 07:01 AM

[Migration User]

Hi,

Just thought that this KB article might help you out here
http://service1.symantec.com/support/ent-gate.nsf/docid/2007090713043654.

--Ian

Message Edited by Ian Mcshane on 06-10-2008 03:31 PM

[Migration User]

Unfortunately no one hint from that KB artikle helps. I do not have a problems with firewall. I been adjusted time and connections count limits, but it do not help. This strange messages still came in.

There is one more screenshot


I just note that this kind of messages do not have "direction" description! It is main distinguishing feature that makes them different from normal messages!

[Migration User]

did you find a solution for your problem? Because I recognized nearly the same problem.

Several mails from one sender without a subject line are not delivered with the "Action: Abort".

The sender got a message that the mail has been rejected.

Does someone have an idea about a sultion?

[Migration User]

Hi

could you please indicate which product and version/build please?

thanks

[Migration User]

Brightmail Symantec Mail Security Version 7.6.0-6

[Migration User]

A first recommendation is to upgrade your system to the latest build 7.6.1-14, as it will improve several features also related to Message Audit Log.

Regards

-m

[Migration User]

Dear Mattia, I'm really worry about this thread and his solution.

I have the same trouble, and a couple of week ago, I wrote to Beastie, asking if he found any solution.
No reply from him.

Then I opened a case (320-116-648) on Symantec Online Support, with "critical" relevance (about 24.000 mail a day results aborted). The only action Support did, was to change the issue to "important" !! (congrats!)

Then I saw the update available to 7.6.1-14.
I read the document about all fixes included in the minor release update.
No one is concerning issue reported in this thread.
However, I was sure Support usually force people to run last version : ), so I upgraded my appliances.
Nothing changed about these huge quantity of aborted messages.

Then I called Symantec, here in Italy, and asked for a day (it has a cost!) support on-site, with a technician.
He said that seems that my smtp connection receives a RSET command, maybe (i said maybe) due to external devices. We are now working with a Cisco consultant (it also has a cost!) about debugging the traffic on port 25.

Please, have u got some real advice? We will appreciate that a lot...
Sincerly, your customer.
Luca

Message Edited by Unicatt on 06-25-2008 06:06 AM

[Migration User]

Luca,

thanks for your comment. I understand your concerns and I also agree with you in how the software upgrade won't totally solve this issue.

My note, given the general thread topic, was more to indicate that some fixes in 7.6.1-14, do improve the Message Audit Log precision, however they're not at the level we all desire yet :)


The main point is that this is 'not' an issue, rather a limited logging of what happens during the SMTP connection (i.e. at the network level), therefore the cause of it may likely be more 'outside' the box than inside.

Symantec is aware of the impact this situation has and is working to improve this feature over the next releases of Appliances Software.

Best Regards

-m

[Migration User]

Ok.

Thank you for the reply.

 

Luca

[Migration User]

Hi all.

I do not found any solution jet. I can not investigate or troubleshoot the reason of this messages...

My appliance is SMS 8380. The software running is 7.6.1-7 version. Updates status shows that there is no any more current versions avalaible.

[Migration User]

Hi,

 

please see my last post. At the moment an effective tool is to refer to logs (filterhub/maillog) set to INFO level in order to understand what happened to those messages. You can use remote syslogging to reduce the impact of the extended logging on MySQL log tables.

 

Also, you should definitely see the next version available: 7.6.1-14 on the GUI. If not, please have a look at your conduit logs as there may be connectivity issues.

 

Regards

 

[Migration User]

Hello Everyone,

Was there a solution to this issue? We have the same problem on our 8240 with the latest software.

Thanks

Tom

Message Edited by Gorbash on 08-26-2008 12:08 PM

[Migration User]

in our case the problem wasn't the SMS. The reason for this problem was the symantec firewall infront of the SMS. ^^

[Migration User]

I wrote on this post before the summer.

Our problem was some "real work" mail that could not reach us, due to action taken "abort message", from SMS8300.

 

We removed the inspection features of our Cisco firewall, on SMTP protocol.

After that we had no more alerts, from our users, about that issue.

 

However, we still receives about 25.000 mail a day, with abort message verdict. But it seems that these messages are only spam or malformed mails. No more real work mails are blocked.

 

We have a case still opened with symantec support, to investigate this issue.

Like Matia Boldrini said in a reply post, I start thinking that this could be a lack of information to code the error in a better way. I don't know if I wrote in a comprehensible way, sorry for my english.

I' ll keep this topic updated with any, possible, relevant news from symantec support.

Bye

Luca

 

 

 

 

 

[Migration User]

Generally the most common reason for the "abort message" is a loss in connection during the message transaction without a specific reason. As Matia stated, the only way to prove this is through logs and potentially a packet capture.

 

99% of the time this is caused by a firewall or upstream device mishandling the message or because of the message being spam, and the spammer getting impatient and disconnecting before the entirety of the message is sent.

 

If it is spam the error can be safely ignored. If not, first place to check is upstream devices and work your way down.

 

 

Hope this helps. :smileywink:

Message Edited by TomC on 08-28-2008 11:18 AM

[Migration User]

Here is a little more background. The mail is from a trusted source, and is set up for permit everything as regards SPAM. Only mail from the specific sender with Excel file attachments have the issue. Plain mail from the same sender comes through fine. Even test spreadsheets with a couple of plain rows, no graphics, charts, or other fancy features exhibit the issue. Large quantities of other mail with Excel attachments from other senders comes through fine.

Tom

[Migration User]

Could be a timeout issue... I would probably suggest calling into support though. If there is slowness in sending the attachments it could time out and cause the abort message entry.

 

Does it happen with any other types of attachments from that sender?

[Migration User]

Testing with other attachment types was not done. Your suggestion will be tried at the next opportunity.

Thanks

Tom

[Migration User]

Hi Matia,

 

We are using SMS 8260 with the latest vesion & build i.e. 7.6-1.14, but still we r getting the same issue.

 

Infact we have increased the connctions and threads as well as disable the SMTP filtering on our check point tooo, but still no sucess.

 

Also the message audit log takes tooo long to get the details. Infact if we check for yesterday log itself, ituse to take approx 7-8min.

 

Our daily mail-flow is around 0.8 million.

 

Rgrds,

SAM

[Migration User]

We are having this same issue. It is a pretty major issue because every day there are legit emails being aborted. Is there really no documentation on what "abort message" is caused by? Still no solutions for this?

[Migration User]

take a look at your firewall, most times the firewall causes the "abort message" issue.

[Migration User]

What aspect of the firewall causes this? Obviously it isn't being blocked.

[Migration User]

Hi,

 

This can be caused by anything upstream that causes a delay, is your firewall performing any SMTP inspection?

You could check your firewall logs for the timestamp in MAL to see if it dropped/delayed anything as part of that conversation.

You can also try extending the session timeout value within Brightmail but I wouldn't say that is a recommended permanent action more a troubleshooting step to see if there is latency at some hop.

 

--ian

[Migration User]

---

itp_j wrote:
We are having this same issue. It is a pretty major issue because every day there are legit emails being aborted. Is there really no documentation on what "abort message" is caused by? Still no solutions for this?

---

We have a KB article around this.  http://service1.symantec.com/support/ent-gate.nsf/docid/2007090713043654

 

The KB search can be found at http://entsupport.symantec.com

 

--ian

[Migration User]

Did you find a solution for your problem? Because I recognized nearly the same problem.

Several mails from one sender domain without a subject line are not delivered with the "Action: Abort Message".

The sender got a message that the mail has been rejected.

Does someone have an idea about a sultion?

Thank you

Rafael Mellone

[amxtaylor]

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

[Migration User]

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.

Regards,

Adnan