SPAMCuda Corporate Frequently Asked Questions and Answers

How can you help the corporate or ISP client stop spam?

The SPAMCuda software is available in both 'appliance' form, with an included computer system, and as a 'raw' software product in binary form. In both cases the underlying environment is the Unix system known as "FreeBSD".

What Email Systems does SPAMCuda operate with?

Basically any. Specifically, SPAMCuda has been used with various Unix-style implementations (e.g. Sendmail, etc) and also with Windows NT/XP Server systems such as Exchange. It is designed to work with any SMTP-capable email transport agent without regard to the final delivery platform or operating system. So, for instance, if you have an old VAX/VMS system, SPAMCuda will even work with that!

Where does the SPAMCuda system "sit" on a corporate or ISP network?

The system can sit either on the "outside" of a firewall, or, if you prefer, it can sit "inside". The only requirement is that it must be able to receive SMTP transactions, and must be able to initiate them to the final delivery system, if you intend to run the software as an "appliance." The software can also run on the same system that currently processes your email, if that machine runs FreeBSD 6.x or above.

How does it work?

The SPAMCuda system looks at all email that is received for you, and makes a determination on whether or not it is spam based on various criteria which include but are not limited to:

• Is there something wrong with the SMTP protocol transaction itself?
• Is the mail to and from the same address, and did it not originate from the local machine? It is likely spam; spammers frequently stick YOUR address in the "FROM" line in order to trick spam filters into returning it to you! Not nice - but SPAMCuda catches that little game.
• Is it from a country code that is known to be full of spammers?
• Is the connection originally from an IP block that is notorious for abuse? These blocks are typically all outside the United States, where US law cannot reach. Some are owned explicitly for the purpose of spamming. We simply refuse to talk to any of those (few) addresses.
• Does the mail contain HTML, executable, or "PIF" attachments?
• Does the mail contain certain words that mark it as being spam? If so, how many?
• Is the reverse DNS either missing or forged?
• Does it contain a lot of misspelled words?
• Has the sending domain been marked as "high security"? If so, (e.g. PayPal) then heightened scrutiny is performed on the connectioin level specifics (e.g. DNS matching, etc) to validate that the message really IS from the claimed site.

and many more.

All of these criteria are looked at in context to determine what to do. The message may be refused outright (if the SMTP rules are violated), it may be bounced back to the sender, it may be passed unmolested, it may be quarantined or it may be thrown away silently. Most messages are either passed or returned.

If a message is returned in error, the sender will get a message explaining what has happened. They may easily resubmit the message to you with the headers intact - if they do, their address will be "white listed" and from that point onward email from that user will be delivered to you unmolested.

Why is SPAMCuda better than the other solutions available in the market?

Several very important differences are present in SPAMCuda - and not in the other solutions being peddled to consumers and small businesses for spam control, including:

• We block more spam! Most user-loaded spam software has an effectiveness rate from 50 - 90%. SPAMCuda, in its default configuration, blocks 99% or more of all spam attempts! Spam control software that is less than 95-99% efficient is simply useless; you may as well hit "delete", since you'll be doing it anyway. Only an integrated, system and protocol-level approach such as SPAMCuda applies can approach the goal of stopping all spam from reaching you.
• SPAMCuda operates at the protocol level. Other spam-interdiction solutions you can buy look at the messages in your inbox - which is too late. SPAMCuda is able to stop the majority of spam before it ever receives it, simply by examining the transmission "in process" and determining that it is fraudulent. If your spam software is operating on your mailbox, then you are losing much of the information necessary to make the "is this spam?" decision! No product that loads on your end-user computer can act at the protocol level, and without that capability, anti-spam software is crippled at best in preventing you from being innudated with ads for "male enhancement products."
• By operating at the protocol level, SPAMCuda saves you time, storage and money, and improves your system's safety . By not storing messages for you that are spam, you avoid downloading them and bringing them into your computer. While increasing numbers of users have broadband connections, the fact remains that even if you don't care about disk strorage, transmission speed and the total amount of data you move around, every time you bring in a message to your system you potentially expose your sysetm to viruses, trojan horses and worms. SPAMCuda keeps these risks away from your machine.
• By operating at the protocol level, SPAMCuda does NOT return bounces to forged FROM addresses. This is one of the major problems with "post-processing" solutions. By not operating this way, we can offer a challenge/response function that is not succeptable to being tricked into spamming someone who has had their mail address forged into the message headers.
• SPAMCuda is capable of maintaining separate "spam" and "white" lists for individual users, with individual control available by either traditional text editor ir via an included web interface program. A system default is, of course, supported. Finally, if you wish we 'export' our master spam list that is operated here; a configuration option permits automatic "fetches" of this list if you desire for your system list.

Are there any limits on the number of user accounts?

No. SPAMCuda does not impose any limit on the number of user accounts or even domains that it will serve email for. We do not believe in "per-user" licensing schemes - you're buying a product to serve your business needs, not a noose around your neck which forces you to spend huge amounts of additional money as your business grows.

In practice, SPAMCuda will handle more volume of traffic than your final delivery sysetm can by very large margins. If for some reason you need more performance, the appliance machine can be simply swapped out for a more powerful computer. If you are running the software product, of course, you can simply perform the same type of upgrade.

Is there any satisfaction or money-back guarantee?

We recommend that you try the package available on our public 'single user' or 'small office' service, which has a free trial available, in order to evaluate the system's efficiency and accuracy for yourself. No guarantee is as good as personal experience!

How much email can I have in my email box?

Each account is limited to 20MB (20 megabytes) of storage, although this is currently a "soft" limit and not enforced. We reserve the right to charge additional credit(s) for excessive use. We encourage you not to leave email on the server for excessive periods of time unless you have some overriding need to do so.

How effective is SPAMCuda?

No spam blocking system can be 100% effective.

But here's where SPAMCuda is different from the other solutions on the market - while most spam protection systems are at best 80% effective in stopping the spam from getting to you, SPAMCuda typically boasts effectiveness rates in excess of 95%! Indeed, in trials that have run for more than a year, during which more than 500 spams a day per email box have been encountered, SPAMCuda typically has allowed one or two messages daily to pass that it should have trapped.

That's darn good.

Lesser solutions that simply mark the messages as spam don't help you, and neither do ones that download the spam and then put it in a quarantine folder. Those chew up both your disk space and bandwidth, and worse, force you to deal with your spam manually anyway. After all, do you really need someone to stick a "SPAM" line in the message header for you to know that an email advertising "Viagra" is spam?

How do I know what SPAMCuda is doing?

SPAMCuda writes log information for every message that it blocks into your own personal log file. You can turn the log on or off, examine it at will (again, over the web), and clear it any time you'd like. If you don't clear it the log will roll over after about 2,000 spams have been recorded. For most users, this is a couple of weeks of spam - for those who get spammed heavily, its still a few days worth of traffic.

SPAMCuda doesn't hide what its doing from you - we think you should know what's being filtered and why. with SPAMCuda, you can see that information any time you'd like - from anywhere in the world.

There is mention of "challenge/response" in your description above.....

Yes, there is, and for good reason.

A spam solution without it is not a solution!

Let's examine this. The ideal spam-fighting software would trap all of the spam, trap none of your real email, never make a mistake, and leave you with only clean email in your mailbox, with the senders oblivious to the fact that you are running this software. It would also require zero effort on your part, ever, to accomplish all of this.

That's unobtainable - but it is the ideal against which spam-fighting software should be designed.

Most spam-fighting software operates in a "post processing" mode. That is, the mail system receives the mail, the spam filtering software looks at it, makes a decision on whether it is spam or not, and then either rejects it, passes it on to you as "regular" mail, or perhaps quarrentines it for you in a "brown list".

Unfortunately, all post-processing software operates at a severe - and in our opinion fatal - disadvantage - it cannot do anything with the original SMTP (email) transaction, since that's finished before it ever gets the message to look at, and it has lost all of the state information from the transaction itself.

That's unfortunate, because our statistics say that better than half of all the spam can be rejected with absolute certainty before it is even received.

However, this can only be done if you are operating at the protocol level. It is obviously impossible to reject spam before you receive it if your software doesn't even look at it until reception is complete.

What's worse, once the protocol has been closed, you can't safely return notifications to the sender of the email if you suspect it is spam. If you attempt to do this, then any spam that has a forged "From" header in the email (that would be basically all of them!) ends up spamming (by you!) the forged victim's address with your (bogus) rejection message. Many competitive systems do exactly this, and it earns them (rightly so) the hatred of other users on the Internet who are victim of their poor design decision. There is no fix for this if you post-process messages; the only possible action you can take is to not issue rejections or challenges at all! Needless to say, this leaves open the possibility that you will silently throw away perfectly good email. Losing good email without notice to the sender, so they can take corrective action, is not acceptable under any circumstances. Forcing you to examine a "brown list" of quarrentined email is likewise not acceptable - if you need to do that, you may as well "just hit delete" and not pay for, or use, any spam blocking software at all.

An effective system must provide a way for users who are challenged to get around it. You want to block spam - not legitimate email. A system that simply says "I think you tried to spam someone" and gives a legitimate sender no way around its decision is by definition defective, because it will throw away perfectly good email. Can you afford to have customers who you never hear from again?

Many competing spam solutions include "hooks" into centralized databases known as "DNSRbls", or "Realtime blacklist" DNS servers. This is a poor implementation choice for several reasons. First and foremost, it gives spammers a central point of attack that disables or radically slows thousands of individual mail servers all at once! Second, these "RBLs" block legitimate email senders frequently - and while a listing can be "appealed", that's a manual process that must be initiated by the person on that address. With dynamic IP addressing common today, and the proliferation of "owned" (hacked) machines being used to send spam, it is unlikely that the spammer is even still USING the RBL'd address by the time someone tries to send email to you from it. Third, email blocked by a "RBL" is an absolute block - you never see it, and there is no means of override made available to a legitimate sender. And finally, RBLs are both ineffective and unnecessary to actually stop spam - in short, using them can do more harm than good.

SPAMCuda does not use DNSRBLs, yet obtains superior results to those systems that rely on this "technology" to identify spammers.

In short, SPAMCuda suffers from NONE of the above problems. Most if not all competing systems suffer from one or more of these shortcomings.

Since SPAMCuda operates at the protocol level, it is able to (and does) examine the context - and content - of an email transaction before it sends it on to be filed in your mailbox. More than half of all the spam is never examined for content, because it fails the protocol-level checks - these are tests that do not fail legitimate messages, but often fail spam - especially spam that is sent from "hijacked" machines, which have become the most insideous and difficult to interdict sources of spam traffic.

Further, SPAMCuda can and does issue "challenges" to possible spam sent to you, without the risk of collaterally and unintentionally spamming the victims of forged email "From" addresses. Since SPAMCuda does NOT generate queued email, it is impossible for SPAMCuda to generate UBE (spam) itself. However, a legitimate email sender who tries to talk to you, and who gets "caught" by your spam filter, will get a challenge and be able to override the filter - immediately, and on their own.

Finally, SPAMCuda is written entirely in "C". By not using "toolbox" systems such as "PHP", SPAMCuda entirely avoids the security risk of unknown code flaws in "public" toolboxes - flaws that all too often show up only after systems have been compromised.

How much does SPAMCuda cost?

SPAMCuda is extremely cost-effective; pricing depends on the exact configuration, whether you're looking for an 'appliance' installation or straight software.

I need more information or help....

Use the "Email Us" link on the left of this page, and we'll get right back to you!