These services claim themselves to be a spam fighting tool. Ironically, they facilitate another time of spam. Forum and Comment spam.
I'm definitely tracking a rise in the number of these types of services, used for posting comment spam - and signing up to post on forums.
(I've even seen normal email spam - 'appear' to come from disposable email addresses. There are so many services around - easy to find ones that don't setup SPF etc)
I know many services, including mine, do have anti-abuse features (rate limiting address allocation, other pattern detection and blocking mechanism), however you can't always tell a legitimate user from an abusive user. For what it's worth 10MinuteMail gives out millions of addresses for each time I hear about anyone posting spam on a forum or anything like that, so I think that the "good" users far outnumber the "bad" ones.
At any rate, ignoring the flaws in the approach that a unique email address is a good way to tell good signups from bad ones, I guess I'd like to ask two questions:
1) Why are temporary email services that much different from GMail/MSN/Yahoo/Personally owned domains/etc... when it comes to abuse prevention on a given forum?
2) Does anyone have suggestions on improving the recognition and blocking of abuse versus legit usage? I absolutely detest forum spam and would like to prevent it if I can help.
Yes that's the sort of thing. But ideally that should be available without signing up. To get an idea of what is possible - ie is it worth even bothering to signup.
Like I had no idea if supported geo-queries, and/or full-text queries. (seems not?)
At the moment we only support what's documented in the SBQL docs, but we're open to any suggestions you have. Other features can be implemented as add-ons, if the demand is strong enough. Note taken about the docs only being available after signing in. Thanks for your feedback!
The problem I have with these sort of services (and its nothing specific to signalbox) - is seem to be aiming at the wrong market. Need to think bigger.
For something like 100,000 records - in general a pretty standard instance of mysql can cope just fine. A lot of the time the database you get free with shared hosting, can cope with queries on this sort of size database just fine (as long as they have indexes). (Or the free database you get with heroku)
... true yes you have to do a bit more sysadmin tasks - maybe even backups etc. But all very doable.
As a beginner at sysadmin tasks, I start to struggle with mid-size datasets. A couple of million records. This is when backups begin getting a pain. Query optimization is actully required. Things start getting painful. full-text search is non trivial. geo-indexes are cumbersome.
But its harder finding a database provider for this sort of size. getsignalbox's doesn't even consider this possibility (other than the 'get in touch') - it might well be able to cater. But talking at $200+ a month, which starts to get serious.
+ this sort of mid size is where the cloud could excel, where sysadmin tasks start to get non-trivial.
Another thing missing - is a simple bulk upload - to be able to import a midsized dataset to be able to try out the service. Even if that is a 200Mb CSV file :)
Our service isn't aiming to be a cloud platform like Heroku nor a database like Amazon SimpleDB. Our aim is to help client developers by removing the need for bespoke server and database for each and every project. API development often involves a lot of repetition. We aim to remove some of that repetition so that developers can concentrate on creating a rich experience for their users. We're all about everyday widgets, mobile apps and rich JavaScript sites.
We've got a lot of features around the corner including a user management engine, powerful add-ons, data import/export and so on. It's early days for us. We're building the product we want to use, and hope others will too.
You can't make a CNAME on a naked domain. (well you can, but there are implications, like your MX records not working - so its not going to fly)
So they either need their current DNS servers to be able to internally resolve the A records of the CDN. But it needs a setup that can replicate the geo-replication that otherwise Alamai handles. Possible but not easy.
Or needs a webserver that just performs a redirect. And put its IP in the DNS. technically easy, but its another server to maintain. And at nasa 'level', it wont be a single server. It will multiple servers - probably geographically distributed.
(or they can pay for a service that handles this - which means needs budget)
The least expensive way would definitely be a redirect on nasa.gov to www.nasa.gov. I really don't think this would require multiple servers for volume (a single very small static file), though redundancy would be smart.
They've obviously chosen the "web browsers handle it mostly, we don't have to think about it" option, which is almost as good, requires zero operational support, and is free.
I hadn't thought about the idea of configuring their DNS to return live results of (essentially) proxied Akamai lookups, which would eliminate the problem of hard wiring their A record to IPs under Akamai's control. That's a neat solution, do any of any the major nameserver sw pkgs support it?
I feel like providing one or both of these services should be something Akamai can do for them... The web standard of www.foobar.com and foobar.com isn't exactly new by this point.
The unusual part of nasa.gov is that all pages and assets are served by Akamai.. www.nasa.gov CNAMEs to Akamai. I'm sure that's not unheard of, though I've never noticed anyone else doing it.
So for nasa.gov to go to the same servers without the ugly redirect hack, you'd have to set nasa.gov A records to Akamai addresses. That would probably require a bunch of their servers in Anycast'ed address space, syncing content, etc. Non-traditional for Akamai, but not impossible.
I wonder if NASA gets a special deal from Akamai. No one else seems to have this problem, and most people who can afford to pay Akamai can certainly afford the hardware and admin costs to run their own primary web infrastructure.
You send data to sphinx (when you update it), and its indexed right away.
The original disk-indexes (updated by a batch process is still available)