[From_old_site] Greycasting: a distributed heavy duty greylisting implementation or Nothing beats /bin/rm for pruning a database

At work, I maintain a mail filter serving a 5 digit number of users. Naturally, this attracts a lot of spam. To reduce the impact, greylisting is used.
A few simplifications have been made: only the domain of the email sender is recorded. This is to cope with systems that change the envelope sender for each retransmission. Likewise, only the /24 IP address prefix is recorded (in order to be friendly to GMail/HotMail users).Historically, there’s been huge activity peaks with bursts of up to 20 million emails a day (1 minute samples). This is over 200 mails/sec and was not healthy to the performance of the cluster — due to overload, legitimate mail were tempfailed leading to long delays in email delivery.To avoid any single point of failure it is desirable avoid the use of a central greylisting database so a distributed technology is needed. Continue reading

UFC-crypt or how my code ended up in your Linux box

Back in the dark ages, I read the papers analyzing the Morris Internet Worm. In order to protect my employers systems, I wanted to do proactive password cracking.

This, however, was painfully slow. A SUN 3/50 could do some 5 password checks a second. This was because the Crypt(3) function does 25 slightly modified DES encryptions using the supplied password as the encryption key.

The number 25 had been chosen to make things slow on the machines available back then. The designers did the mistake of choosing a very slow DES implementation. They should have used an optimized one, doing 1000 iterations.

Optimized Crypt implementations had been made but they were only available in closed security research/hackers circles. So I set out to write my own one. Continue reading