We have implemented three main ways for a Karmasphere client to query Karmasphere. They are:
The BQuery protocol is the most expressive protocol and is strongly recommended for all new applications.
BQuery permits the transport of URLs, not just domain names! While some domain names are wholly owned and operated by spammers, some URLs in mails refer to public hosting sites where a spammer merely has an account. It is vital that a reputation system be able to distinguish between http://www.example.com/users/good/ and http://www.example.com/users/spammer/. Existing "URI blacklists" list only at the domain level and are unable to make this distinction. The BQuery protocol can transfer the entire URL, and permits the matching of URLs at many levels of granularity from exact URL to sub-tree.
BQuery supports corroboration to increase confidence in the verdict. Two identities may each be good, but when used in some combination, they may represent an undesirable connection, which must then be decreed bad. Domain authentication mechanisms like SPF represent just one case of this. BQuery permits the inclusion of multiple identities, with associated context information, in a single packet. The Karmasphere server supports an increasing range of algorithms which decide the overall reputation of a transaction, not just of any single identity presented as a part of that transaction. Without BQuery, these algorithms must be created and maintained at every client installation.
BQuery reduces upgrade effort at the client. When a reputation source appears, or worse, disappears, only the Karmasphere server needs to be updated. Previously, every client installation needed to be updated, making it difficult to add new sources, and disastrous when an old one disappeared. Clients may be grouped using feedset identifiers, and the configuration of a feedset may be easily updated through the Karmasphere web interface or by a local server administrator.
BQuery saves bandwidth. The BQuery response contains only the information requested, which may include all the opinions contributing to the verdict, or just the overall verdict and summary. Including multiple identities in a single packet reduces the number of reputation requests, and requests may be sent using UDP or streamed over a single TCP socket. The user has very fine control over the bandwidth usage of the BQuery protocol.
BQuery saves administration and processing time. BQuery permits the seamless merging of custom reputation sources with existing data. Managing and distributing a custom reputation database is hard work. Database lookups are disk and CPU intensive, and require considerable administration if the database must be distributed to multiple machines. Karmasphere specialises in high performance distribution and lookup of complex reputation data. The BQuery protocol allows you to query your own private data sources in the same query as public sources, and perform corroboration between all these sources.
| Feature | DNS | BQuery |
|---|---|---|
| UDP | yes | yes |
| TCP | maybe | yes |
| Multiple identities in one query | no | yes |
| Corroboration support | no | yes |
| URL support | no | yes |
| Email address support | no | yes |
| Wildcard support | some | yes |
| Identity context support (PRA vs mail-from vs HELO vs Sender vs From) |
no | yes |
| New logic requires configuration changes at | every client | the server |
| Configuration changes made by | the customer | the vendor or the customer, at the option of the vendor |
| CPU burden | general-purpose client | special-purpose server |
| Local caching | uses DNS cache | requires cache or local node |
| Bandwidth | baseline | estimated 60% reduction |
| Authenticated Queries | based on IP, if at all | support for username/password authentication |