The version of NT mail server software (SLMail) I purchased and installed from Seattle Lab was v4.0. I made my purchase about two months after it had been released. I figured that with at least two months under their belt from a major version upgrade should have given them time to get a handle on any major bugs in the program. Boy was I wrong about that!
At apparently random totally unpredictable points in time the SMTP portion of the mail server would suddenly peg the CPU at 100% usage and the server was for practical purposes locked up. The only way out was a reboot. If I was able to get the Services Manager to excruciatingly slowly come up it was unable to stop the SMTP server. But then the reboot presented it's own set of problems. Sometimes as soon as the mail services were starting during boot up the SMTP service of the mail server would immediately jump to 100% usage of CPU resources and effectively lock up the server. It was not really locked up of course. The CPU was just tied up in some endless loop in the SMTP server so that the computer was effectively disabled. Anything else on the server that was attempting to run would go at such an agonizingly slow rate that it was like watching grass grow.
These constant lockup problems would occur anywhere from once or twice in 24 hours up to ten times an any given 24 hour period.
It seems to me that the folks at Seattle Lab must either not have a clue as to what a large daily problem their mail server causes for their customers or they simply do not care.....
The Seattle Lab NT mail server like all NT mail servers that I am aware of creates log files... But in the NT mail server software I have seen other than Seattle Lab's NT mail server they have the capability to delete log files after they are either out of date or after the log files have grown to a predetermined limit. The SLMail NT mail software creates separate log files for the SMTP and POP3 sections of the mail server. The administrator can select to have the POP3 logs run forever writing to a single log file or it has selections options for having the mail server start a new log every day, week or month. But it does not provide any automatic mechanism for deleting the huge log files. for the POP3 portion of the mail server will sit there taking up huge chunks of space until they are manually deleted.
The log files for SMTP server are even worse. The SMTP log file will simply continue to grow day by day, never closing the file. In order to delete these old SMTP logs the Seattle Lab mail server requires that both the POP3 and SMTP servers must be stopped in order to delete the old SMTP log files.
It is somewhat mind boggling to me that anyone would design a mail server like this. Can you imagine designing a piece of software that is a central part of running a business (in this case an email server) that requires you shut down your mission critical service in order to delete bloated and useless old log files?
In my case the daily POP3 log files that can be deleted manually without stopping the mail server grow at the rate of 30 to 50 megabytes each day. And that is when you have options set for recording only the very minimum information to the log files. In fact with the POP3 log files set to this minimum reporting requirement the logs are virtually useless for figuring out is causing a problem. In order to have POP3 logs that contain enough useful information to be of any value in debugging problems, in my case with the relatively small volume from my mail server, the logging must be set to save about 150 megabytes of log for each and every day. And as I said before, none of the old useless logs are automatically deleted. The must be deleted manually.
The log files for the SMTP server service are even worse in their implementation. There is no provision in Seattle Lab's NT mail server for deleting SMTP logs without shutting down both the POP3 and SMTP services. To give you a feel for what this is like for me - once again I have a relatively small mail service actually handling email for about 100 commercial domains. In addition I have less than 10 active mailing lists with the single largest of them having less than 2,000 subscribers. In a single weekend, after I had shut down the POP3 and SMTP services and deleted all the old log files, by Monday the SMTP logs were just slightly less than 100 megabytes in 14 files. Some of those 14 files can be deleted without shutting down all email services on the server but the single biggest log file named SMTPLog.txt is slightly larger than 78 megabytes. This file that is already huge will continue to grow each day and can not be deleted without first shutting down both POP3 and SMTP services.
If you and your clients like receiving hundreds of pieces of SPAM (unsolicited email advertisements) daily then then Seattle Lab's NT mail server might be the NT mail server of choice for you!
Within about four months after I installed Seattle Lab NT mail server software on my server I noticed a rather large increase in the volume of SPAM mail coming to myself and my email clients. I received several phone calls from clients wanting to know why. I did not have a good answer for them but at that time I was not aware that the SLMail NT server software was somehow telling the folks collecting email addresses to sell to the SPAMMERS the email addresses for all my mail clients. Then I happened to notice that a mail address that I had created for myself when I initially installed Seattle Lab's NT mail server had hundreds of pieces of SPAM going into it. I had never used this mail account to send or receive anything. I had never even set up this mail account in my email client on my workstation. Yet there was incoming SPAM piling up in the mail box waiting for some fool to download it.
At that point I began to look a bit closer at what was happening. Every single email account mail box on my server was receiving dozens of pieces of SPAM junk mailings every day. The only exception to this was mail accounts that were created in the last couple of months. All accounts older than a few months were receiving this barrage of junk mail.
After watching this closely for over six months I have come to the conclusion
that there is a bug (Seattle Lab would probably call it a feature) in Seattle Lab's NT mail server
that the people who collect and sell email addresses to the SPAMMERS could
exploit. I believe there is some way that the SPAMMERS can query the mail
server and it will tell them the names of every email account set up on the mail
server. That is the only explanation that makes any sense to me in light of
what I see happening. In investigating this problem I found that every email
account on my mail server that had been set up for about 2 to 3 months was
receiving piles of junk mail every day. Only new accounts were immune from the
onslaught of SPAM. Then within a few months those newest mail accounts would
gradually begin receiving more and more junk mail. How could the purveyors of
all this junk mail know the names of all email accounts set up on my server
unless Seattle Lab's NT mail server is telling them?
Prior to purchasing Seattle Lab's NT mail server for a number of years I was using NTMail on my server. From the beginning I set up the NT Performance Monitor to produce a running graph of key functions/events of the mail server. The types events that I have always monitored include the number of pieces of mail waiting to be sent, threads, POP3 processor usage, SMTP processor usage and the number of open file handles. After running NTMail for a number of years and now running Seattle Lab's NT mail server for more than a year I have a very good feel for the comparative speed and efficiency of the two mail servers.
When Seattle Lab's NT mail server is compared in speed and efficiency to NTMail it comes in a distant second place. Relative to the NTMail server I was accustomed to prior to purchasing this one, Seattle Lab's NT mail server is an inefficient memory hog. Seattle Lab's NT mail server in my experience is not capable of sending and receiving even half of what NTMail can handle while requiring more than double the system resources (CPU cycles and RAM usage).
Seattle Lab knew about and had the fix for the serious lockup problems all their customers were experiencing. Yet they sat on the fix and did not issue an incremental upgrade for six months.
Seattle Lab introduced a new list server product at the same time they released Seattle Lab's NT mail server v4. It is a full featured list server but loaded with serious bugs. About one year after releasing their list server they decided to pull it off the market. At the same time they also decided to stop all technical support for this product. Never mind that they have quite a number of customers using this product. Never mind that among those customers were a number of them that paid for "Premium Technical Support" for this product and the those contracts were still in effect. They simply stopped technical support and had their support people remove the list server software from their computers. To top it all off, Seattle Lab did not inform it's customers that had recently purchased the product that they were dropping the product and immediately stopping all technical support. In my opinion this demonstrates gross neglect and regard by Seattle Lab for the people who purchased their software.
This is the second incident that I am aware of in about a year where Seattle Lab demonstrated they have no concern or regard for their customers and the problems they encounter in running Seattle Lab software.
You may be the lucky recipient of similar gross neglect and regard for it's customers when you purchase software from Seattle Lab.
Good Luck if you purchase anything from Seattle Lab..... You will probably need it!
| These web pages are for the sole purpose providing information about my experiences with Seattle Lab's NT mail server and listserver products. The facts and opinions presented are mine alone. It is not my intention to liable Seattle Lab. I have attempted to present an honest and fair presentation of the facts of what happened and my opinions about those facts. If there is any misstatement of material fact in this document it is unintentional and will be immediately corrected once I am convinced of the misstatement. |