Spamcop blocking Jaguar

[neraudia]

Just switched over my organization's e-mail to Jaguar after asking support specifically about e-mail blacklisting, and being told by support, "There are no domains which blacklist Jaguar's IP." So I have to say I was terribly disappointed to find my very first test e-mail to pass through a Jaguar forwarder was blocked by Spamcop.

What am I supposed to do, say to our users, "I know your e-mails have been working perfectly before, but our new provider is hosting spammers?" Jaguar, do not give me a black eye for having chosen you from the slew of possible hosting services.

Yes, I've already opened a trouble ticket. Is there any reason to be hopeful about doing so?

Edit: Our account was moved to a different server, which seems to have solved the problem. Thanks.

[gerilya]

I would venture to guess support answer was misleading due to bad choice of the words: it's virtually imposible to know that no domains blacklist certain IP.


If my memory serves me correctly, Spamcop used to be hosted here (not anymore), call me a paranoid, but I think it's somehow related

[jason]

For the most part, blacklisting hasn't been a problem with the JPC servers, but occasionally they do get blacklisted. This is especially true of new servers where clients are still being added. It doesn't take much for someone to sign up for an account and start spamming with it before anyone at JPC knows anything about it. While they do put several checks into their instant activation system to prevent fradulent orders, sometimes it is impossible to know that someone is going to use the server to spam.

When Jag finds out that they've got a spammer on their network tehy waste no time in shutting the site down, and when they do end up on a blacklist they do everything the need to do to get off of it quickly. And once the client base on your server "settles down" and they stop adding new accounts to it you'll rarely, if ever, see your server find its way on to a blacklist again.

--Jason

[Spathiphyllum]

Originally posted by jason
...While they do put several checks into their instant activation system to prevent fradulent orders...

Maybe this belongs on its own thread but I'll follow-up here first since it's related to account checks and limitations.

Are accounts on Jag servers CPU limited? By that I mean, are the CPUs throttled to a max of, say 5%, of total server CPU timeslices per account? Or are accounts allowed brief bursts of up to 100% of CPU time?

The reason I ask is that I've seen wildly varying response times on some of my CGI applications that do not depend very much on the time of day. Typical "off" hour performance usually improves as bandwidth demands are lowered and response times shorten... not unexpected - but that is not the case with some of my more demanding scripts.

So I don't know if the varied response is due to a CPU cap or a function of memory load or something else. It does not appear to be due to bandwidth limitations.

Spathiphyllum performed forum search for recent updates to CPU limiting... they exist but implementation not specified
Search for "CPU limit"

[neraudia]

Thanks gerilya and jason for your replies. Les from the sales dept. has initiated a move of our site from patriot to liberty, which he believes should solve the problem. Regards to Les for his prompt attention.

As a newbie here I was less than encouraged by tech support's reply, "Please contact the recipients not to use the unreliable spamcop service which does not provide any details as to why they have blocked the server. You can also contact spamcop to remove the block. Let us know if you need further assistance."

[Gwaihir]

Originally posted by neraudia
What am I supposed to do, say to our users, "I know your e-mails have been working perfectly before, but our new provider is hosting spammers?" ...

Yes, I've already opened a trouble ticket. Is there any reason to be hopeful about doing so?

Yeah, that sucks, bigtime! Still, it is what I had to tell my users too last week after my account got moved over to Orion to find some breathing room (Oxygen is rather busy these days). Don't forget to add to that "it shoud fully wear off within a week".

It is not that JAG likes to host spammers, not at all. It is just that they can't always be caught up front and though they are thrown out reasonably fast once they start their spamming, it still gets a lot of legitimate mail users on the same machine in trouble.

That spamcop list is particularly bad: it takes long to wear off and there is no way to clear a server manually. Spamcop knows it and says on its own pages that it shouldn't be used as a "hard" selection method, but unfortunately many companies do it anyway

A ticket helps somewhat: JAG is serious about throwing spammers out the door and getting of blacklists again, for the spamcop one though, I fear there is no such thing as "getting off fast".

I guess when I was offered a move to Orion I could have noticed it was a brand new machine, filling with new accounts and could have asked them "not yet but save me a spot". Still I find it a pity that the techs didn't think of that. Isn't it a well known fact that "new" machines are plagued by spammer use and relatively high amounts of runaway customer code in the first weeks?

[Gwaihir]

Originally posted by Spathiphyllum
Are accounts on Jag servers CPU limited? By that I mean, are the CPUs throttled to a max of, say 5%, of total server CPU timeslices per account? Or are accounts allowed brief bursts of up to 100% of CPU time?

I don't think there are caps like that.

It makes sense to try and serve each request as quickly as possible, so you will want to allow short 100% bursts. So IF there is a check, it should be some form of "average resource use" counter.

I think it is monitored by humans only: if a machine has a surprisingly high resource use, the tech go look at what causes it.

[Spathiphyllum]

Originally posted by Gwaihir
I don't think there are caps like that...

While I didn't find hard policy stating caps, there was innuendo. Nevertheless, I think your reasoning is correct. Short of a runaway process, quick bursts are optimal assuming user load isn't running high.

Another user (who will remain anonymous) notified me that the CPU processing as you described was indeed the policy on his server. That is music to my ears.

Thanks for the follow-up.

[gerilya]

Originally posted by Gwaihir
Still I find it a pity that the techs didn't think of that. Isn't it a well known fact that "new" machines are plagued by spammer use and relatively high amounts of runaway customer code in the first weeks?

Although it's a valid point, I wouldn't expect that much from the techs, but I personally find it a pity that support responses like the one quoted above by neraudia seem to become a common practice here.

I admit that response times here are good, but if it comes at the price of response quality, I don't mind to wait a little more

Just my 2 cents.

[Spathiphyllum]

Originally posted by gerilya
I admit that response times here are good, but if it comes at the price of response quality, I don't mind to wait a little more

You have just experienced a microcosmic staple of economics...

In business you can provide only two of the following to be profitable:

You can make things fast.
You can make things cheap.
You can make things good.

So I guess you would categorize this episode as fast and cheap.

Jag still offers a good balance of services.

[Ron]

Quality. Speed. Price.

Pick 2.

[Spathiphyllum]

Same song, different verse... But pithy is good.

[jason]

From my experience, when I get poorer responses to my support requests, they seem to be coming from the remote techs. If I submit a ticket during normal business hours, and it is handled by someone sitting in the JPC NOC, I get a much higher quality response. When I submit a request at night and it is handled by a "remote" tech it usually isn't as good of an answer and suffers from ungooder grammar.

Jag said in a chat a while back that they are moving toward less of a reliance on remote tech support and wiill be handling more of it in house. So I suspect that things will only be getting better.

--Jason

[gerilya]

Guys,

Thank you for a lesson in economics, but I respectfully disagree with how it was applied to this particular case

With $2-5 hostings popping up like mushrooms after the rain, I don't think Jag prices are cheap. They might be 'cheap' for someone who needs as much bandwidth as one can get, but this is clearly not the case for the domains we host here. We also rarely use support and like I said before don't need that fast response time. So, we actually pick 1, not 2, and I really don't think it's too much to ask.

[gerilya]

From my experience, when I get poorer responses to my support requests, they seem to be coming from the remote techs. If I submit a ticket during normal business hours, and it is handled by someone sitting in the JPC NOC, I get a much higher quality response. When I submit a request at night and it is handled by a "remote" tech it usually isn't as good of an answer and suffers from ungooder grammar.

Jag said in a chat a while back that they are moving toward less of a reliance on remote tech support and wiill be handling more of it in house. So I suspect that things will only be getting better.

Jason,

This is a valid point (should I add as always ) but I consider any support response as representing the company regardless physical locatation of the tech. Hiring remote unskilled workers and then blaming them is a bad excuse, it's just lame, IMHO.

Also, I just recently had a very unpleasant experience of having support ticket answered by someone with good English skills, but apparently with no technical ones. Beside being very unprofessional, I felt like it was kinda rude.

So, I guess linking support quality to bad English doesn't make justice