This plugin catches spam which has had a faked Received line inserted before (ie below) the legitimate Received's. The fake line is assumed to contain the same from address which also appears in the first legitimate Received. This is cheched by a simple regex on the second (from bottom) Received line after extracting the address from the first. In the normal mail transfer process, the ``received by'' address of the previous hop should appear as a ``received from'' address in the following, but the first ``received from'' should not reappear.
I do not know how widespread it is for spam to show this feature. I once was targeted by a spam botnet which inserted such an additional header line and wrote this module to filter these messages. An undisputable advantage of this plugin is that it does not have any false positives - legitimate mail has correct headers and will not be erroneously identified as spam. So there is no harm in using it, and its score can be set quite high. (I even set it so high that mail with a positive result will always be marked as spam, but you might want to be more cautious.)
Download archive containing the Perl module and an example SpamAssassin configuration file fragment.
Here is a patch which adds a more sophisticated search function to Pascal Rigaux's hexedit. With it, you can search for hexadecimal numbers with a bit mask, and at alignments of an arbitrary number of bytes and at 1, 2 and 4 bits. You can also search for non-matches.
The client program of the Samba project, smbclient, allows to download and upload directories recursively. However, the recursive or non-recursive status can only be toggled, not set to a defined state, and cannot be determined except by counting the number of toggling commands since the program startup. The same goes for some other boolean switches. This patch modifies the semantics of the toggling commands, to allow both setting and querying. It has been submitted as bug #5028, but since it has wishlist severity, it may spend some time in the queue yet. See there for a more detailed description of the changes.
This patch makes the role-playing game Nethack Falconseye (see here) print out its messages to the terminal window too, which helps post-mortem analysis no end.
gnuplot is a script-controlled plot program. Despite its name it is not under GNU licence (just one of those coinicidences...), but it is allowed to patch it for one's own use.
One thing which I have always found problematic in gnuplot is labelling logarithmic axes so they look nice in TeX. For an axis extending from 1 to 106, for instance, one would like the labels 1, 10, 100, 103, 104, and so on. Though the gnuplot terminals (= output formats) pstex, pslatex and epslatex allow TeX code in labels, this is not easy.
I have just solved this problem for the second time. The first solution I found years ago involved setting the labels manually with the set x/ytics command. This caused the problem that minor tics were disabled when major tic labels were given in this way. This patch for gnuplot 3.7.1 (and perhaps other 3.* versions?) changes that. You have to give the tic labels in ascending or descending order for it to work.
Recently I hit the same problem again in version 4.2 of gnuplot. It is different enough to make porting the old patch a nuisance. Instead, I found a different and better solution: gnuplot allows to give a printf format for printing the labels. With this patch, numbers in exponential notation are automatically converted into TeX notation if you give a dollar sign after the percent sign initiating the format directive. As superscript exponents can only be typeset in TeX's math mode, you also have to enclose the whole number in dollar signs. So by saying "set format "$%$ g$", you will obtain labels like 1, 100, 0.01 for numbers close to 1 and like $10^{-6}$ (⇒ 10-6) and $3.514\cdot10^{15}$ (⇒ 3.514⋅1015) for numbers with larger exponents.
The $ after the % is allowed with all format directives, but will have an effect only for %e and %g. As an aside, the patch also contains a rough but useful estimation of the width of a TeX source string. Otherwise gnuplot just takes the string length, which is wildly wrong for control sequences and can cause the plot to be shifted spuriously to the right.