SubSpool folder question

Question asked by Jay Altemoos - 4/2/2018 at 8:35 AM

Unanswered

Good day everyone. I have a question on the SubSpool folders. We have noticed that our drive space on our server has been slowly filling up for no reason. Upon investigation as to why, I uncovered a situation where SmarterMail is leaving alot of XXXXXXXX.eml.tmp files hanging around in each of our SubSpool folders (currently we have 10). The XXXXXXXX.eml.tmp files are really old, in some cases 4-6months old and they just keep accumilating in there. Currently about 30GB worth. Is it safe to delete these files without an issue? I made sure to check our Spool and only current email delivery is in there and nothing that pertains to any of the old .eml.tmp files that are there. We are currently running SmarterMail Enterprise Edition Version 15.7.6600, does the latest patch (15.7.6663) specifically address this issue?

11 Replies

Reply to Thread

Joe Wolf Replied

4/2/2018 at 8:45 AM

I'm on the latest 15.x and I checked my Spool folders and found about 100 .tmp files that were old. I didn't see any pattern to the dates and times. I deleted all of them.

It looks like this is or was a bug with SM at some point in time.

-Joe

Jay Altemoos Replied

4/2/2018 at 10:12 AM

Hi Joe. Thank you for the advice. It still has to be a current bug, I found .eml.tmp files in there from a few days ago that were not associated with any emails in our current spool. I compared the file name with what our current spool has in que. So hopefully someone from ST sees this and can answer whether the latest patch addresses this or not. I plan on upgrading to the latest patch regardless.

Jay Altemoos Replied

4/2/2018 at 11:09 AM

Reading through the latest update from ST it only addresses the Drop folder:

• Fixed: Spool does not clean Drop folder of orphaned HDR files.

So according to the listing on the update page, updating to the latest version is not going to address this problem with the orphaned .eml.tmp files in the SubSpool folders either. I even went as far as checking the Quarantine folder thinking maybe when ClamAV grabs an infected email that's the reason these files are getting orphaned. That theory was shotdown because one of the example orphaned files in the SubSpool folder did not match anything in the Quarantine folder for that same day. I even checked a few other days to be sure, but did not find it there either. So who knows why the file got orphaned to begin with, but I cleaned up 33GB of space from the spool just from the orphaned files dating back to November of 2017. So this issue has been happening for awhile and I'm surprised no one else has brought this up yet. I would have never noticed it if I hadn't been wondering why my server disk space was getting low and the numbers didn't add up to what the GUI report was showing me on users mailbox sizes.

I am just going to have to keep an eye on the spool folder size and babysit it I guess until someone at ST sees this post and responds to it. Hopefully they can address this soon.

Jay Altemoos Replied

4/3/2018 at 7:14 AM

I just want to give anyone following this thread an update, I checked my SubSpool folders this morning and indeed SM is not cleaning out the .eml.tmp files. This morning I found at least 50+ orphaned files between all our SubSpool folders.Granted it's not alot, but if this is not being paid attention to, you could accumilate several GB's of data in there that doesn't need to be there. So there's definitely a bug happening here. Everyone might want to spot check there SubSpool folders to see if you have several GB of orphaned .eml.tmp files in there like I had. I must have cleaned out at least 200+ files yesterday when I first discoverd the issue that dated back several months because I had no idea this was happening.

Hopefully someone from ST sees this and responds.

Employee Replied

4/5/2018 at 7:24 AM

Employee Post

Hello Jay, is the file extension .eml.tmp, .tmp.eml or .eml_tmp?

Jay Altemoos Replied

4/6/2018 at 6:45 AM

Hi Matthew,

The most of the extensions are .eml.tmp, a few of them are .eml_tmp

Here's an example of one that is orphaned there as of this morning: 347233627713.eml.tmp

I went through all the SubSpool folders this morning, I have a total of 92 orphaned TMP files between all the folders. 87 of them are .eml.tmp and 5 of them are .eml_tmp

Still puzzles me why they are getting orphaned like that. I monitored one of the SubSpool folders and noticed that the .eml.tmp file would match a actual .eml file in the folder. So it's almost as if it's duplicated. They both have the same size and date/time stamp. So when the message is being received by the server, does it enter as a .eml.tmp file and then SM renames it to a .eml when it's fully received and ready for delivery?

Employee Replied

4/6/2018 at 8:25 AM

Employee Post

Hello Jay, I can't find anywhere in our code where we would write a .eml.tmp file to the spool at the moment. the .eml_tmp files are used for rewriting things like a footer or bcc, but they run through a common function to write those back to the .eml file and delete the tmp file so unless it was getting a really bad exception I don't know why those would be orphaned.

Jay Altemoos Replied

4/6/2018 at 9:28 AM

Hello Matthew. It's puzzling me for sure. So it sounds like to me that the .eml.tmp files don't belong there at all then. I am guessing it's safe to say I can delete them. They keep populating everyday. Not sure why they are hanging around. Maybe what I will do is write a batch file to go through each SubSpool folder and delete all the .eml.tmp files out of there, since it sounds like they don't belong there in the first place. Is it safe to say that would be fine?

Kayasidh Kasyapanun Replied

4/9/2018 at 12:36 AM

I found some .eml_tmp from time to time as well. I'm on 15.7.6607

Employee Replied

4/9/2018 at 8:34 AM

Employee Post

I think it would be safe to just write something to delete them as I don't believe those .eml.tmp files are ours. Do you have any third party tools that scan the .eml files?

Jay Altemoos Replied

4/9/2018 at 9:29 AM

Good afternoon Matthew,

Thank you for looking into this and repsonding back to me. Our mail server has the following installed, builtin SA and ClamAV in the SM installation, a external SA installation and external Message Sniffer. Everything is housed directly on that server, so it's all local and the 2 external anti-spam programs have been installed for at least 2 years now without issues. I would have noticed the space issue long ago if either the external SA installation or MessageSniffer would have been acting up. From what I saw, the issue must have surfaced around Nov. of 2017 (that was the oldest .eml.tmp file that was in there). Looking through my Revision History on that server, we updated to 15.7.6474 back at the end of September 2017 and then to 15.7.6600 in the beginning of Feb 2018. So it puzzles me as to why this started in Nov 2017. No patches were issued and only tweak I did in that time frame was some scoring sdjustments to the external SA installation. We don't have an external anti-virus installed either.

I will just write a script to delete those files and be done with it. It's just really odd. I appreciate the time you took to respond and have a look into this. Thank you.

Back to Community Threads

Please leave this box unchecked

11 Replies

Reply to Thread

Tags

Related Knowledge Base Articles