There are a number of technologies vying to protect us from spam, by providing channels for legitimate senders of email to prove that any given message comes from them, thus allowing them to build a reputation (and get whitelisted) while spammers' domains and/or mailserver IPs get bad reputations, and they can't spoof messages to steal the good reputations of others.
This is entirely separate to tools like SpamAssassin, which try to analyse emails once they've arrived, and allow a recipient to judge their spaminess regardless of who they've come from.
It's also entirely separate from things like HashCash, which work by letting senders attach a mathematical proof to their message that shows they've invested a second or so of computer time, thus distinguishing them from people who send thousands of messages per second.
Read more »
I'm writing a unit test for a bit of code that connects to a server. The bit of code has parameters - hostname, username, password, and details of what to fetch from the server.
The thing is, the infrastructure it's placed in expects it to store the password in encrypted form. It has to use a separate component that contains a hidden master key to decrypt the password when it's required, and to encrypt a new password given to it.
Also, since the application will be fetching lots of different things from different servers, it quite reasonably has a 'host' abstraction that can be referred to by lots of data collection modules; it keeps a central list of hosts, and my component is passed a Host object.
But when writing a unit test for my component, this is a pain. The way the central list of hosts and the crypto component are accessed involves going through a 'session' object that also has lots of things like listening sockets, database connections, and much other complexity afoot.
Read more »
For a project, I'm having to write some Java code to talk to a Domino server.
Finding any references on how to do this is a BIG pain, so for posterity, here is what I've found.
Read more »
It's always struck me as odd that IP routes a packet to a transport-level protocol such as UDP, ICMP, or TCP and then lets that protocol handle routing it to an application process.
Since an application is likely to require a few different types of service for different parts of its operations, shouldn't the specification of the target application be more important than the transport mechanism?
Wouldn't it make sense to be able to send a UDP request to 'port 80' just as easily as you can send a TCP request, rather than requiring the web server to bind separate UDP and TCP listener sockets?
These chains of thought led me to design the MERCURY protocol.
Read more »
In Object-oriented programming, things defined in a class can have one of (usually) three access levels: public, private, or protected. Public things are accessible to all users of the class, private things are only accessible from other things defined within the same class - and protected things are accessible from within the class and its subclasses.
However, I have noticed that protected methods are often rather insufficiently documented.
Read more »
Computing | alaric | 
Wed 13th Sep 2006 12:37 pm | 
Comments (3) 
Subscribe