I own and operate a small ISP operation in Dallas Texas. I provide commercial web hosting and e-commerce for my customers. I currently host over 100 commercial domains. I did not and still do not provide any dial-up Internet on-ramp services. My primary niche in the market is that I guarantee my customers that I will get their web pages into the top 30 positions in a minimum of 8 of the top 10 search engines for their specific key word search phrases. I only guarantee I will get my customers somewhere in the top 30 positions for their keyword search phrases but to date I have successfully gotten ALL my premium support customers into the top 10 results on better than 8 of the top 10 search engines.
In the type of ISP business I am running I need to provide email server
software for the domains I host. I offer an unlimited number of email accounts
for all domains hosted on my server. I also provide a list server as part of
this service.
Prior to purchasing the Seattle Lab email server software for NT, I was using the competing product NTMail from Gordano in the UK. I was not unhappy with the functional operation of NTMail. I became fed up with Gordano's marketing policies. I felt they were taking advantage of their customers when they priced their upgrades higher than the price of the full product a year before. They were forcing their customers to upgrade by a deceptive practice of providing a "Free" upgrades to fix bug problems. But what they did not tell me in advance was that the "Free" upgrade actually removed necessary components of the base package. Then later they offered the components they removed, and that I had already purchased, as part of the new version upgrade or new product at an exorbitant price greater than the original purchase less than two years previous. The NTMail and NTList software was very efficient. If it were not for what I considered as predatory sales policies by Gordano I would have continued with NTMail and NTList..
My problem with the NTMail software was that they had removed the part of their software that would allow you stop SPAMMERS from hijacking (open mail relay) my mail server to send their garbage. That function was present in the NTMail software when I purchased it but was removed later in one of their free upgrade fixes. It was advertised as an upgrade fix for bugs and no mention was made that they were removing what was for me a critical part of the base software. They created an all new product out of what they removed and expected their customers to to purchase the new package named "Juice" that I felt I had already purchased as part and parcel of the base NTMail software.
Once Gordano Software removed my ability to turn off 'open relay' my mail server IP started showing up on the lists maintained by MAPS, ORBS and IMRSS Spammers listings. Many ISP's use these services listings to block Spammers using 'open relay' servers to send their garbage. Suddenly a lot of outgoing mail was unable to reach it's destination because the mail servers where it was addressed were refusing to accept any email from my mail server.
At this point I had to make a decision. I could stay with Gordano Software
and it's NTMail and NTList and pay their exorbitant predatory prices to get back
the functionality I had already paid for - Or I had to find another solution
entirely. Obviously I opted to try the Seattle Lab Seattle Lab's NT mail server and SLList
products.
But I made a big mistake. I had an ISP friend that recommended that I consider Seattle Lab's SLMail product. He was a small ISP that was using it for his dial-up customers email and he said he had no major problems with it. When NTMail removed the capability of my being able to run their software without having it set up as an 'open mail relay server' and then requiring me to purchase the same functionality again forcing me to by their 'Juice' product I started looking for a new solution.
After going over the product information on the Seattle Lab web page and also doing my due diligence looking for product reviews both positive and negative (I did not find any negative reviews) I decided to give it a try. I purchased a package from Seattle Lab that included:
This change was a mixed blessing. It included the ability for me to let my
clients access their email from my server while not running the mail server in
'open relay' mode. But it also forced me to have to manually re-enter all my
email clients, domains and lists. There was no way to migrate from NTMail to Seattle Lab's NT mail server
without starting over from scratch.
Prior to purchasing Seattle Lab's NT mail server I loaded it on a non-production server and did some testing. No significant problems showed up in the limited amount of testing I was able to do. If in my testing I had actually set up all my domains, email clients and mailing lists I would have become aware of a huge problem with Seattle Lab's NT mail server. But in my testing I set up only a couple domains, a few clients and one mailing list. It turned out this was another mistake as it was not sufficient to encounter the problems that came up when I actually loaded the software on my main production mail server.
Uninstalling my old NTMail software and installing the new Seattle Lab's NT mail server software went without any major problems. It was a huge pain making the change requiring several days work as all domains, email accounts and mailing lists had to be re-entered from scratch.
That is when my problems with Seattle Lab's NT mail server started for real and thus began my
descent into mail server hell.....
The version of Seattle Lab's NT mail server 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.
By the time I switched to this new mail server from Seattle Lab I already had some unhappy clients. At that time my server was being listed as a SPAMMER and many major domains were blocking all mail from my mail server. That was seriously hurting my clients. So by now going back to the old NTMail software was not an option. Fool that I can sometimes be I decided to stick with this new mail server from Seattle Lab. I figured my experience must be an aberration.
At the time I thought I was using sound reasoning at deciding to stick with it and get this problem fixed. I figured that this software had been around for long enough that if all their other customers were having the same problems I was having they could not possibly have stayed in business. At this point I was spending many hours on the phone with Seattle Lab technical support each week. Technical support guys spent many hours with me going over all the configuration settings, tweaking this and adjusting that trying to fix the problem. At no time during all this did anyone I talked to at Seattle Lab ever give any indication that anyone else in their universe was having the same problems I was having. All that combined to convince me that my outlandish problems were truly an aberration that was unique to my NT Server installation.
With the assistance of technical support we somehow got the SMTP server to
not peg the CPU at 100% usage so often and even managed to get it to where the
services manager in NT could occasionally actually stop the service when it went
to trying to hog all the CPU resources. All this took place over about two and a
half months. The most intense portion of it was during the first month. There
was little measurable progress after that. We had it down to where it would
sometimes go as much as three days before it would suddenly lock up the server
again. Preventative re-boots or restarting the software more often did not have
any apparent beneficial effect. It would lock up at totally unpredictable random
points in time but toward the end it was not averaging more than three or four
times each week.
For almost three months I remained tied to that damn mail server as if it
were a ball and chain locked to my ankle. There was no way to predict when it
would lock up again. When it locked up mail in and out of the server would stop.
You can imagine how happy my clients were with me by this time. During this
entire debacle I lost about a third of my combination web hosting and email
services clients. I could not blame them. If I were in their place I might have
found a new ISP myself. But since I could not leave myself I was stuck with
getting this damn mail server fixed once and for all. From the time I first
installed Seattle Lab SLMail on my server for about three months I could not
take a day off or relax out of earshot of a phone and a way to restart the
computer when the mail server did one of it's random lockups.
One day in my perpetual fog of being physically and mentally worn I finally realized what a fool I had been to put up with this lockup problem way too long. I had lost a full one third of my business and I finally realized that at this rate the prospects of things getting better any time soon were somewhere between slim and none. For some reason since the fellows at Seattle Lab technical support had tried so hard to help me with my lockup problems I decided to tell them that I was finally packing it in and I would immediately begin looking for a different and hopefully better piece of mail server software to use to beat myself to death with.
To my amazement when I told the person I normally spoke to at Seattle Lab technical support what I had decided to do he told me that he thought there might be a solution to my problem. He suggested that I join their beta test group. At fist he did not come right out and say it but he initially hinted that getting the current copy of Seattle Lab's NT mail server that was in beta just might solve my major lockup problem. I explained to him that I had thought about that early on and had asked about how to go about joining their beta support group. I had been given the email address of the person in charge of the beta group and had been told I would have to contact him. I continued to explain that I had written to the beta supervisor twice and had received no response. The technical support guru said he would take my email address and hand carry it to the beta group supervisor and make sure he was aware I wanted to join his group. By this time solving this problem was working on me like an addiction. Having been given the possibility and the hint of a strong probability that a solution might be coming quickly I plunged ahead.
As some insurance that possibly I could get the right persons attention and actually get my major problems with Seattle Lab's NT mail server solved I gathered up every email address I could locate for people working at Seattle Lab. On June 13, 2000 I sent the following email to all of them. I learned later that it was this message that got into the right persons hands that moved Seattle Lab off the dime where they finally became concerned about their customers problems.
Date: June 13, 2000
Subject: SLMail & SLListGentlemen,
Before I get into the specific problems I am having (and have had for over two months), I want to say that in every conversation I have had with the people working in your technical support, they have been without exception courteous and have tried to help. But for all their efforts to help it has not solved the problem. The problems are not as severe now as they were early on in this process and John Gresbrink did lead me to where there were some internal looping problems in SLMail and helped me resolved that issue. If we had not at least solved some of the problem issues I would not be writing this letter about it now as I would have either gone out of business or I would already have moved on to another product to try to resolve the problem.
All the assistance I have received has been when I called your technical support office on the phone. I tried a number of times to resolve some of the issues via email but each piece of email I have sent has effectively gone into a "Black Hole" and disappeared.
I had been running NTMail on my server for about four years before I purchased your SLMail and SLList products. In retrospect I should have paid the exorbitant upgrade price and stuck with NTMail. But because of their predatory pricing policies and the way they forced purchase of their products by removing functions from existing products and placing it in new products, I knew for well over a year that I needed to find a new mail solution. Because your product was recommended to me by another ISP that I have some confidence in his opinion, I purchased your mail software to replace NTMail.
The version of NTMail that I was running did not have the ability to block SPAM hijackers while still allowing my POP3 customers to send and receive their email. Your version 4 of SLMail advertised a solution to this problem and with the recommendation of my friend it seemed like a good idea at the time to switch to your product and abandon NTMail. I had been placed on the ORBS and MAPS spammer lists and had to resolve the problem quickly.
Now, two months later, having lost about half my customer base specifically because of problems with the mail system after making the switch to your product, I am still having major problems with the mail system. The single biggest problem that has cost me half my business is that the POP3 server hangs up and stops processing mail. The degree of the problem is in direct proportion to the amount of mail passing through the system. So having lost half my customer base has by itself reduced the hangup frequency by about half or maybe a bit more.
Your support people recommended to me several times that I should move backward to version 3 of SLMail which they assured me would solve the hangup problems. But that possible solution is not a valid option for me. I purchased your product for the mail relay features you advertise in version 4. If it were not for the mail relay problems I would be better off going back to NTMail. For all my objections to their predatory practices, the NTMail product is stable and reliable but I could not stay in business and have mail from my server blocked because of my being listed in MAPS and ORBS.
I have several real problems with the operation of SLMail and SLList that I would like to resolve. But there is one single overriding problem that I have with your SLMail. I can not keep it running. The POP3 portion of the software continually hangs up or freezes up, the processor goes to 100% usage and there is nothing that can be done to get it going again except rebooting the server.
In order to keep the server running most of the time I have had to set the server Scheduling service to stop and then restart the POP3 service every two hours. That resulted in a big improvement. With that poor but temporarily liveable work around in place I have managed to stick with your product for the last month. But today there was another system lockup and the Scheduling service was not able to stop the POP3 service and restart. The result of the lockup today was that I lost another customer. This was a customer that had been with me for almost five years and was one of my best customers. I can not blame the customers I lost. If I were in their position I would probably have done the same thing and found someone that could provide me with reliable mail service.
On May 25th following the advice of your telephone support I wrote to betaadmin@seattlelab.com asking to be added to your beta test group. I explained that I am an experienced analysis and programmer and have run and participated in quite a number of beta programs in the past. I thoroughly understand the necessity of beta testers providing detailed feedback about problems that will allow the programmers to duplicate the problem in order to arrive at a permanent fix. I have not received any response to my request.
On the same day, May 25th, I also sent an email to techbin with a question about mail relay. This is June 13th. About 2 minutes ago while I was writing this letter an email response to my inquiry of May 25th finally came in so my remark about all my mail disappearing into a "Black Hole" is no longer true.
As I stated above, I have a number of problems with the operation of both SLMail and SLList. However all those problems except for the single problem of the POP3 server hanging I can live with and hopefully resolve over a period of time. But I can not continue to live with the POP3 server freezing up.
So, the bottom line is this, either I get some proactive assistance from Seattle Lab to resolve this freezing up problem or I will have to find another solution for my mail problems. I am not saying you have to solve it instantly. I am more than willing to work with your beta group or anyone else there to arrive at a solution. But I am unwilling to leave things go as it has for the last two months in the hope that you will at some point in the future come up with a solution.
I have a very limited number of options before me at this point. Without help from Seattle Lab there is no way I can continue trying to resolve this and stick with your product. If I do not get some kind of reasonably rapid response to this letter, and begin some dialog with someone that can help work with me to resolve the freezup problems I will be forced to take the following actions which I see as the only viable options available to me.
1. I will have to uninstall your mail software and restore the older NTMail software. At the same time I will have to purchase their upgrades to give me the features for mail relay.
2. I will initiate a process with the credit card company to contest and reverse the charge for purchasing your software.
3. I have kept a log of the problems and many calls I have placed to your support office and I have the phone bills to prove it. I will put up a web site that includes all the details of attempt to use your products along with all the results. I will then register the web site with all the major search engines. I should explain at this point something about my business. I am a small ISP that specializes in commercial web sites most of them heavily involved in e-commerce. I guarantee my commercial customers that I will get them into the top 30 listings on all the major search engines or their web hosting will be free. I charge a premium for this service. With over 70 commercial domains I have never had a customer that I had to provide free service for more than two months. If it goes that far and I have to move back to NTMail I can guarantee you that if anyone goes looking for your type products using any one of the major search engines and the primary keyword listings you employ they will find the page I created about your products listed BEFORE any listings for your domain. I am an expert at getting web sites to the top of the listings and I will put in as much or more time and effort on this web site as I do for my paying commercial web sites.
Please to not misunderstand what I just explained as a threat. I don't intend it in that way. I am a very reasonable person and would prefer to not do any of the three items listed above. If I get some kind of proactive response from you in actually helping me solve this problem I would prefer to stay with your products and not use any of the limited number of options I listed above.
Again, I do not expect an instant fix. I realize that the probability is that the only short term fix to the freeze up problems will require me to run beta level software. That is not a good practice on a machine that is mission critical for my business but it is something I am willing to try in an attempt to resolve the major problem I am having. I have a short fuse at this point. I will not wait around doing nothing almost a month waiting for a positive response as I did waiting for an email response from technical support for about three weeks.
I would truly appreciate some help from someone there who is willing and able to help me resolve this problem.
Dan York
At the time I wrote this letter I did not know if it would have any effect or
not. I was to learn later that it was probably this letter that caused Seattle
Lab management to finally begin considering if they should actually do something
about this problem for me and all their other Seattle Lab's NT mail server v4.0 customers.
On 6/14/00 I suddenly received my first email from the Seattle Lab's NT mail server beta group. The technical support guy had followed through on his promise to let their beta group supervisor know I wanted to join and I was added to the beta test list . At least at that time I thought it his efforts that got me on the list. As you will see later it was probably the general message I had sent to every email address I could find at Seattle Lab that finally got some reaction from them. In any event shortly thereafter I posted my first post to the beta group. This is a copy of what I posted:
I was added to the beta list today. I have no idea what problems are being actively worked on. I have not been experiencing the problem referenced in this piece of mail. So, I would like to know where I can find a copy of build 3380. At this point I am running the release version build 1381. There is one overriding problem I have that I am hoping has been or is being worked on. I have a continuing problem where SLMail stops processing incoming mail from the SMTP server and locks up the processor usually at 100% usage. When it hangs at either 100% processor usage or sometimes at 0% processor usage there is nothing that can be done other than rebooting the server. I have a work-around in place where the scheduling service is set to stop and restart the POP3 service every two hours. This continuing stop/start has helped but has not solved the problem.
Within an hour one person on the beta list answered my post with a link to where I could find what I was looking for and another member took pity on me and actually attached a copy of the beta build I had been told to ask for. A few hours after that the Seattle Lab beta group supervisor (Lee Thompson) also answered my post with another link to where I could find the beta copy I was looking for.
I immediately loaded the beta v4.1 build 3380 on my server. With this
installation my lockup problems stopped. The almost daily occurrence of the CPU
locking up with 100% usage by the SLMail SMTP sever was over. What a relief it
was. At this point I thought my major problems were licked and it would be much
better from now on....
It was within 24 hours that the following message was sent by Lee Thompson (beta group supervisor) to the members of the beta group list. The bold print in the message below was added by me for emphasis:
From: "Lee Thompson" <lt@seattlelab.com>
Subject: SLmail Beta: Open for Discussion...
Date: Thu, 15 Jun 2000 15:44:47 -0700
SLmail 4.0, as most of you know quite well - unfortunately, has a number of
serious problems that cause it crash or otherwise stop functioning. With
the exception of the beta team, our other customers are waiting for fixes for
these problems.As we have been making great progress in the last few weeks, I have a question
that I'd like to ask all of you - since you are our customers.
Given the severity of some of the problems in SLmail 4.0, after #2509
(improper bouncing) is resolved should...
[ ] SL ships SLmail 4.1 and fix the other open issues in a follow up (we'd
start work immediately of course) release?[ ] SL keeps working on SLmail 4.1 until all reproducible problems are
fixed?[ ] Other (fill in comment)
I could not believe what I was reading... Could the folks at Seattle Lab possibly be this bad. I had no idea that all the other poor schmucks that bought or upgraded to Seattle Lab's NT mail server v4.0 might have been having the same problem I was having. I still was not positive that all the other users of Seattle Lab's NT mail server v4.0 were experiencing the same severity of the lockup problems that I had prior to loading beta v4.1. The following is a copy of my reply to Lee Thompson's post above:
At 03:44 PM 6/15/00 -0700, you wrote:
>Given the severity of some of the problems in SLmail 4.0, after #2509
>(improper bouncing) is resolved should...
>
>
>[X] SL ships SLmail 4.1 and fix the other open issues in a follow up (we'd
>start work immediately of course) release?Lee,
I was added to the beta group yesterday. The lockup issues with your 4.0 release were so severe that if I had not received a fix for it or had good damn reason to believe I would get a fix for it very quickly I would have been an EX customer - and a very disgruntled customer at that.
I believe you OWE it to your customers to get the major bug fixes to them as quickly as you can.
Since I just joined this group yesterday I don't know what all the issues are that you are still working on but I do know that the lockup problem is severe enough that 4.0 should not have been released until the lockup problem was solved - assuming you were aware of it prior to the initial release.
Even if the 4.1 release introduces new problems but the problems introduced are not as severe as the lockup problem I would still have the same opinion. Release 4.1 right away and resolve the remaining issues as quickly as possible in a future release.
Dan
After I made the above post I began to find out just how common these problems were for Seattle Lab customers. Quite a few other people on the beta list began to sound off about the way Seattle Lab conducts their business. The following email is included because it contains a copy of another person on the beta list that was having similar problems as mine. What makes this one important is that it contains Lee Thompsons reply.
From: "Lee Thompson" <lt@seattlelab.com>
Subject: Re: SLmail Beta: Open for Discussion...
Date: Fri, 16 Jun 2000 09:10:37 -0700On Fri, 16 Jun 2000 11:45:47 -0400, you wrote:
> the failure to have a reliable platform has cost us and our customers
> dearly. I have watched hundreds of emails pass through and this is the first
> one addressing the real issue, you have a release that should be pulled from
> distribution, and at the same time you never notified resellers of the
> issues. I ran for over a year supporting scores of earlier releases with
> almost no issues and then had to deploy 4 techs over 2 weeks to chase our
> tails until finally notified of the issues, disgraceful.Mr. Shulman,
I really don't want this to turn into a debate over what has happened since
this will just distract us from the issue at hand: fixing SLmail and getting
that version into the hands of everyone that has SLmail.So I'm going to say the following this one time:
The problems in SLmail 4.0 didn't make themselves known until a couple weeks
after release and we immediately started working on fixing them. I had
really hoped that the fixes would've been rapid and we the plan was to have a
4.0B by the beginning of February 2000.Obviously that didn't happen and here we are today, after six months and a LOT
of work. I think the program is approaching what I wanted 4.0 (originally
3.3) to be originally.We've fixed a lot of bugs in SLmail 4.1, many of which have been around for a
long time - some were made worse by some of the features added to 4.0; others
came to light after fixing other problems. I'm very proud of the work our
SLmail engineering team has put into SLmail 4.1.In closing I will go on to say that I (and the rest of SL) apologize greatly
for the problems in SLmail 4.0. However, we do learn from our mistakes and,
I hope, our commitment to SLmail with this update shows that.
Here is the voting form again:
[ ] SL ships SLmail 4.1 and fix the other open issues in a follow up (we'd
start work immediately of course) release?
[ ] SL keeps working on SLmail 4.1 until all reproducible problems are
fixed?
[ ] Other (fill in comment)
--
Lee Thompson lt@seattlelab.com
Seattle Lab Inc. http://www.seattlelab.com
Product Manager (Messaging Products) ICQ: 19545760
---------------------------------------------
SLmail Beta Team
As I read the Lee Thompsons reply in the message above I went balistic!!! I could not believe what I was reading. Here is the head of the beta support group saying that they knew within "a couple weeks after release" about the severe lockup problems all their version 4.0 customers were having. What made it even worse from my point of view is that it became clear to me at this point that Seattle Lab had been well aware of of the lockup problems all their version 4.0 customers had been suffering with for six months!!!!
And so now knowing all about the pure hell their program bugs were causing
all their version 4.0 customers here it is six months later they have not
done anything about it. I could not believe it. They have had a fix in
their hands since two weeks after releasing the badly flawed version 4.0 of Seattle Lab's NT mail server
yet here six months later they are actually asking the beta group their
opinion about whether they should immediately release the beta version that
solved the problem. Well duh..... what do you think? Even now a year later it
still boggles my mind to think that Seattle Lab was undecided on whether they
should immediately release an incremental bug fix. For six months - One half of
a year - without supplying the fix all their customers running the then current
release of Seattle Lab's NT mail server was a product that was clearly unfit for the purpose for
which it was sold. And then six months later they have the nerve to
ask their beta testers what they thought Seattle Lab should do about it.
Remember that the second selection on the check box was for selecting to just
leave it alone and supply the fix for their customers at some later undetermined
date when enough other minor issues were ironed out. I was dumbfounded. To
this day I do not have a clue as to why there would be even a minor question as
to what was the right thing for Seattle Lab to do. How could any responsible
company have the fix in hand for a major program bug that made their centerpiece
software unfit for the purpose it was sold and still be unsure whether they
should wait even longer than the six months they had already waited before
releasing the fix?
I found myself impaled on the horns of another dilemma. Seattle Lab had finally allowed me to download their beta copy of version 4.1 and it had solved my major lockup problems. But now I am beginning to face the fact that Seattle Labs lack of concern for their clients had allowed me all their other customers suffer through trying to use the software they paid good money to purchase. They had waited six months with the fix for this major bug in hand before even considering releasing the fix to the overwhelming majority of their customers.
With that knowledge in hand I was concerned about this kind of thing happening again so I began researching again, looking for the right product to replace the software from hell that I was currently running. Then a few days later on June 28, 2000 I received the following email from the president of Seattle Lab, Mr. L.A. Heberlein:
Date: Wed, 28 Jun 2000 16:14:53 -0700
From: "L.A. Heberlein" <la@seattlelab.com>
Subject: Re: SLMail & SLListDan --
Let me start by apologizing for the problems you have had with
SLmail. I've been in the software business for over fifteen years, and I
have to say that the bug we had in SLmail 4.0 was the most vexing issue I
have ever encountered. Although it only affected a very small percentage
of users, for those users, it caused nightmares. We put our most senior
engineers on the case, gave them all the resources of the company, made it
our highest priority . . . and still it took far too long to fix. I know
that email is one of those critical applications you just can't live
without, and that people pick SLmail precisely because of its proven
reliability, and to have this latest version marring a reputation we'd
spent years building up -- let me tell you, we treated it as an emergency.I'm happy to report that SLmail 4.1 is in the field. We subjected it to
every variety of in-house and field testing we could devise, and all tests
show that it fixes the problem in every possible configuration.I'd urge you to download and install 4.1 immediately. Please verify that
it solves all your issues. And if there are any remaining problems or
concerns, please feel free to contact me directly. My contact information,
including home telephone number, are below.Once again, I'm sorry we let this problem get into the field in the first
place, and that it took us so long to expunge. We do believe that it is
firmly expunged now, and we'd like the opportunity to regain your trust and
confidence as we continue to develop what we believe, and what we'll work
hard to convince you, is the world's best mail server.Thanks for using SLmail.
L.A. Heberlein
President
Seattle Lab, Inc.
11730 - 118th Ave. NE, Suite 400
Kirkland, WA 98034
Direct phone line: 425 825 7070
Home phone line: 206 527 2792
Yes, I know after all that had transpired previous to this I should have
known better. But in my defense I was completely exhausted and worn out from
fighting the mail server from hell. I wanted every word of Mr. Herberliens email
to be true. I wanted to believe that Seattle Lab really cared about their
customers. I hoped they would pay more attention to their customers complaints
and would be more timely in their responses. After all Mr. Heberlein did say
"we continue to develop what we believe, and what we'll work hard to
convince you, is the world's best mail server." I am learning how to spell
C-H-U-M-P the hard way.
At this point I settled down into trying to get along with the mail server from hell. I began keeping track of problems and would document then submit the problems I encountered to the Seattle Lab's NT mail server beta group. The majority of bug issues that I submitted during this time were related more to SLList than Seattle Lab's NT mail server. The details of the problems associated with running SLList are discussed in detail in the SLList summary and SLList details pages.
Then suddenly on 10/12/00 without any prior discussion or warning Seattle Lab shut down the Seattle Lab's NT mail server beta list. The following email was sent by Lee Thompson announcing the demise of the beta group:
From: "Lee Thompson" <lt@seattlelab.com>
Subject: SLmail Beta: The End of The Beginning
Date: Thu, 12 Oct 2000 12:39:30 -0700We are reorganizing and (hopefully) improving our beta groups and as such this
particular list is being closed.However, you should have all received an invitation to join the new beta team.
If you haven't received an invitation, haven't responded, you've changed your
mind or if you have any questions please contact our Beta Coordinator -
Roderick Mabry <rodm@seattlelab.com>.This list will be shutdown after this message is processed.
Thank you all for helping us make SLmail a better product and I hope to see
all of you on the 'other side'.
--
Lee Thompson Software Engineer
lt@seattlelab.com Voice 425 825-7000 Seattle Lab, Inc.
http://www.seattlelab.com Fax 425 825-7001 Kirkland, WA (USA)
---------------------------------------------
SLmail Beta Team
In keeping with the established standard of my experience with Seattle Lab, I did not receive another email from Seattle Lab about the beta list. I did send an email to the 'new' beta coordinator requesting to be placed on the 'new' beta list. Typical of my experience with Seattle Lab I never heard any response from Seattle Lab. I should point out there that the above notice I received from Lee Thompson states that "you should have all received an invitation to join the new beta team." which did not happen. And even after sending a message to Roderick Mabry asking to be added to the new beta list the typical response from Seattle Lab was - Nothing - no answer at all!.
If all the significant problems with Seattle Lab's NT mail server v4.01 were fixed at this point
then possibly shutting down the beta group would make some sense to me. But that
was not the case. So now four months after joining the Seattle Lab's NT mail server
beta group the
work I had done collecting , documenting and submitting bug and problem reports
to Seattle Lab about Seattle Lab's NT mail server and SLlist was over.
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 mail server like all mail servers that I am aware of creates log files... But in the 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 Seattle Lab's NT mail server 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.
There is another way that a bug in Seattle Lab SLMail causes random server CPU lockups. When working in the Seattle Lab's NT mail server remote administration, updating either the Relay Filtering or Mail Filtering will cause the CPU on the server to hang when updating either of these settings. This would not be much of a problem if these settings had to be updated infrequently. But that is not the case with Seattle Lab's NT mail server. The reason these two configuration files have to be updated often is because of yet more program bugs!
Relay Filtering - When a client needs to send mail from their email account, if they have not connected to the Internet through an internal dial-up, relay filtering is required. When a valid user is not connected through a local dial-up connection, whenever they check for new incoming mail Seattle Lab's NT mail server is supposed to set a cookie that will allow them to send mail from a remote connection as if they were connected locally. If this process actually worked the way Seattle Lab says it works this would be no problem. But sometimes it works and sometimes it does not. It does not work properly more often than it does. There is an alternative to this automated setting of a cookie that is built in. It allows you to create a list of IP numbers of remote ISP's that will treat anyone attempting to send mail as if they were connected locally. But there is a big problem that can be encountered when trying to enter all the possible IP's that a person's dial up provider might be assigned. Most ISP's will not tell you the full range of possible IP's they use to assign to customers when they dial into their system. That makes it a process of trial and error in getting all the IP's that the customer might use. This is why it requires frequent updates. It also requires frequent updates when new mail clients are added from a new ISP dialup service. In my experience in the normal course of business I am required to update the relay filtering IP configuration list multiple times every week. About 40% of the time, when I attempt to save the updated relay filtering IP list causes the Seattle Lab's NT mail server remote administration to hang. When it hangs it will normally begin using virtually 100% of CPU resources making it difficult if not impossible to resolve the problem without rebooting the server. The problem can often be resolved by simply stopping and restarting the remote administration module. But because the remote administration service is in the weeds using up virtually all the available CPU cycles it takes a very long time to stop and restart the remote administration service.
Mail Filtering - The mail filtering portion of Seattle Lab's NT mail server remote administration is used to filter out SPAM mailings. It uses the MAPS, ORBS and IMRSS real time databases to identify "open relay" mail servers that might be used for sending SPAM. But there is another huge problem. The real time on line databases do not list ALL open relay mail servers that the SPAMMERS use. When I first started using Seattle Lab's NT mail server this was not an overly huge problem but over a few months it developed into a major daily headache. Even when all the available real time databases to reduce the volume of SPAM are enabled there are hundreds if not thousands of 'open relay' servers still available to the SPAMMERS to use. In fact, the SPAMMERS are able to use the real time lists from MAPS, ORBS and IMRSS to know these are the open relay servers they should avoid using so their garbage emails are not filtered out from most responsible ISP's.
Making things even more troublesome, there is an apparent bug in Seattle Lab's NT mail server where it tells the SPAMMERS the account names of all email accounts in the server. This includes the administrative and posting addresses for all mailing lists hosted on the mail server. So the end result of this is the SPAM purveyors of garbage mailings now have the email addresses of virtually every client on my mail server in their lists. This problem is covered in detail in below.
Within six months of beginning to use Seattle Lab's NT mail server the volume of SPAM mail incoming to my server exploded! The number of pieces of SPAM mail addressed to clients on my server slowly increased until each of my clients were receiving hundreds of pieces of SPAM every day even though all the available real time filtering lists were enabled! So I was forced to begin manually entering the IP's of sites sending multiple pieces of SPAM to my clients and mailing lists. As of the time I am writing this I have had to manually add over 400 SPAM purveyors IP's to the mail filtering list.
It is a slow process of opening each piece of SPAM received and adding the IP
of the mail server that sent it to the mail filtering list. Initially having
to do this took two to three hours every day! At this point after
having done this daily for a number of months it only takes about an hour each
day because it has slowly reduced the total volume of incoming SPAM mail. But
the problem of saving these updates to the Seattle Lab's NT mail server mail filtering configuration
file is the same as what happens when saving configuration updates to the 'relay
filtering' page. The mail server remote admin will lock up randomly
approximately 40% of the time when attempting to save the updated mail filtering
list. When it hangs it will normally begin using virtually 100% of CPU resources
making it difficult if not impossible to resolve the problem without rebooting
the server. The problem can often be resolved by simply stopping and restarting
the remote administration module. But because the remote administration service
is in the weeds using up virtually all the available CPU cycles it takes a very
long time to stop and restart the remote administration service.
Stopping and restarting the mail services is required by Seattle Lab's NT mail server whenever you:
In the last section I discussed the log files and the requirement of stopping and re-starting the mail sever to be able to delete the SMTP logs. But that is not the only normal day to day operation where Seattle Lab's NT mail server requires the POP3 and SMTP services to be stopped and restarted. Of the five reasons for stopping and restarting mail services listed above, the first four are items that occur on a regular day to day basis. Changes to the main configuration file is the only item in the list that does not happen regularly - some of the first four happen multiple times some days.
So what is the big deal? After all, stopping and re-starting a service when configuration changes are made is common to most if not all services that you run on NT servers.
Stopping and restarting the mail services when any of the above changes are made would not be a big deal if Seattle Lab's NT mail server could be stopped and re-started quickly and reliably. But that is not the case. Every time I have to re-start the server mail services it is a "crap shoot" on how long it will take. Occasionally the mail services can be stopped and restarted in under a minute. But normally it does not happen that fast. On average it usually takes from 2 to 6 minutes for the mail services to actually stop. When I first started running Seattle Lab's NT mail server there was a bug in it where any attempt to stop the mail services would usually result in the mail services getting hung up requiring re-booting of the server to clear the problem. Later in the beta version I ran the hanging up on re-start problem was greatly improved. But it was not solved - it just became less of a problem! In the version of Seattle Lab's NT mail server that I am running now a normal attempt to stop and restart the mail services works about 90% of the time without forcing rebooting the server.
The real problem here is how long it takes and what happens between the time you begin the attempt to stop the mail services. From the instant you select to stop the mail services until a few seconds after it tries to restart (sometimes up to several minutes afterward) none of your clients can download or send any email. Any attempt by your clients to connect to the mail server results in a message that 'connection to the server was refused'. In addition incoming email addressed to your server is also refused.
This problem of how often re-starting the mail services is required and how
all those restarts negatively effect my customers is not trivial. My customer
base is commercial web sites. These businesses have become dependent on fast and
efficient email in their normal day to day operations. But in my experience with
Seattle Lab's NT mail server what normally happens is that any re-start of the mail services results
in 2 to 6 minutes (occasionally much longer) during which time mail clients
receive the 'connection refused' error message and cannot send or receive mail.
Don't forget that incoming mail to the server is also often refused which can
result in your clients not receiving important email that is critical to their
operation.
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 mail server of choice for you!
I do not know for an absolute fact that an Seattle Lab's NT mail server bug is responsible for this horrendous problem. But I do have a logical reason for believing that a bug in Seattle Lab's NT mail server is responsible. Within about four months after I installed Seattle Lab's NT mail server 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 server software was somehow telling the folks collecting email addresses to sell to the SPAMMERS the email addresses for all my email clients. Then I happened to notice that an email 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 email 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).
So, what has been the direct real cost to me of having in good faith purchased and used Seattle Lab's NT mail server and SLList?
I am not sure what the real total cost has been. It is easy to calculate how much I paid for the products, how much it cost me in long distance phone calls for the many hours spent waiting on hold first and then talking to technical support in an effort to resolve the many problems I have written about here.
I can not calculate with any degree of accuracy what using Seattle Lab's NT mail server and SLlist has cost me in the countless hours I have spent trying to keep it running. It is also impossible to know how much this has cost me in lost customers. When I initially installed and started using Seattle Lab's NT mail server I lost a minimum of one third of my customers. Initially I lost over half my customers because of the email problems that I have talked about in detail here. But over the months after initially loosing over half my customers a number of them came back. Those that came back realized the value of the services I provide other than email and decided that the advantages of remaining as a customer outweighed the problems the Seattle Lab mail system caused.
Another area where it is impossible for me to know the exact real cost has been in lost business I would have gotten if I had not had the the problems I have had with Seattle Lab mail server products. There are hundreds if not thousands of people that claim they will get their customers top ranking with the major search engines. To the best of my knowledge the people that actually accomplish high rankings with the search engines as I do are few and far between. I depend on referrals from satisfied customers to keep my business going. I obviously do not get any referrals from those customers that left me dissatisfied because of the lack of consistent reliable email service. I also do not know how many prospective customers I have lost because the customers who have stayed with me might now be reluctant to recommend me to their friends because of the problems they have had with email even though they decided to remain customers.
Then there is the cost to my existing customers who have stuck with me through all my problems with the mail server. I have had to spend hundreds of hours for over a year working on the mail server, doing maintenance trying to keep it running. If I had not been forced to spend that time working with the mail system I would have spent that time working on and improving my customers search engine rankings. Accomplishing top search engine positioning is very labor intensive. My inability to spend the time I normally would have spent improving my customers index positions with the search engines has to have cost my customers a lot of money in lost business. But once again I have no way of accurately estimating those costs. Those costs I can not accurately estimate are not included in the totals listed below.
| The real costs I can be sure of thus far are: | $899.00 $16,000.00 ~$550.00 ------------ $17,449.00 |
- initial purchase of Seattle Lab
Software - lost revenue dissatisfied customers leaving not returning - long distance phone calls to technical support - real dollars cost and lost |
If I tried to include some cost for the hours I have spent on the phone with
technical support and in keeping the Seattle Lab's NT mail server and SLList products running and even
worse if I tried to include some dollar value to the frustration and angst in
being tied like a slave for over a year to the mail server then the total cost
would be much more than double. I am ashamed to admit that I let this go on as
long as I have. If I had bitten the bullet six or nine months ago and removed Seattle Lab's NT mail server
and SLList from my server I would have been way ahead of where I am now
and the real and incidental costs probably would have been significantly
lower.
As of this writing I am still running Seattle Lab's NT mail server and SLList on my mail server. As soon as I can arrange it I will be getting rid of Seattle Lab's NT mail server and SLList and will install a new mail server. I am in the process of doing due diligence in looking at my options in mail server software that I might consider purchasing. As of this writing I am leaning toward going back to NTMail and NTList from Gordano software. I hate Gordanos predatory pricing policy. It was Gordanos predatory pricing that caused me to look for a new mail server software solution. The software itself worked very well. With NTMail and NTList I did not have any of the problems I have talked about here except for 'open mail relay' and that problem was taken care of in their NTMail add on product named Juice.
Going back to NTMail and NTList will cost a bit less than purchasing a
competing product because I will not have to buy the product from them as a new
purchase. I can use the license I already purchase and then abandoned over a
year ago. That means I would only have to purchase the updates to get my old
software up to their current version.
There is a lot more I would like to tell you about my problems with Seattle Lab's NT mail server.
After I finish writing my review of SLList and also completing the summaries of
my reviews of Seattle Lab's NT mail server and SLList I plan to come back to this section and expound
on some additional day to day problems I believe anyone using Seattle Lab's NT mail server
is likely
to encounter. But right now I don't have the time to say more in this
section. I am having to spend too much of my time working on keeping the mail
server running and providing my clients with dependable service to say all I
would like to say about Seattle Lab and their SLMail NT Mail server software.
It is ironic that for all my problems with Seattle Lab software and the problems and frustrations of trying to keep it going do not have a similar counterpart in my dealings with human beings at Seattle Lab. Without exception when I have talked to anyone at Seattle Lab they have been sympathetic and have given me the impression that they have done their best to help me solve the problems. From the time I initially purchased Seattle Lab software up to now I have had telephone conversations with about 6 to 8 different people at Seattle Lab. But I have never talked to anyone at Seattle Lab that had any real authority in creating their software or in setting company policies and practices. I have nothing but high regard for every individual I have had occasion to talk to at Seattle Lab. My problems with them stem from their policies and practices (in addition to the poor software) and the execution of those policies - not the people charged with implementation. The way I see it the people have been doing their best to do the job they were hired to do but have been unsuccessful in dealing with me due to the root of my problems with their company not being within their authority or control.
Dan York
danyork@dallastexas.net
.
Back To Seattle Lab NT mail server Software Review Home
Page
Seattle Lab's NT mail server
Problems Review Summary Page
SLList Problems Review Details Page
SLList Problems Review Summary Page
| Disclaimer: These web pages are for the sole purpose providing information about my experiences with Seattle Lab's NT mail server and SLlist 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. |