Creating PCB footprints is usually quite easy as most components come in standard packages.
Footprints for ‘magjacks’ (RJ45 with built-in Ethernet transformer) are another thing as different manufactures tend to at least put the LED pins at different positions.

Here is an Eagle PCB footprint I created for the MagJack (MJF13T36L-KF06B3GY-0808) from MoreThanAll sold by Sparkfun.

This one has been proven in production and it works, however you should double- (and triple-) check pin-outs and footprint of your device before sending a PCB for manufacturing using this part. Use at your own risk.

Magjack schematic

Magjack footprint

Download

morethanall_magjack.lbr

The binary for the VLC UnRAR plugin 0.9.8a-20090307 for Linux/i486 have been re-rolled because the packaged version appeared to have been compiled with the wrong settings causing it to fail on certain platforms. The new version should hopefully work okay.

New maintenance release (bug fix only) of the VLC UnRAR plugin. A small number of bugs have been fixed, no new features.
More exciting is the number of new binaries available

Binaries for VLC 0.9.8a available for the following platforms

• Windows XP(/Vista?) 32-bit (works with XP(/Vista?) 64-bit)
• Mac OS X PPC 10.4 or higher
• Mac OS X Intel 10.4 or higher
• Linux 2.6.x x86 32-bit (libc 2.7)
• Linux 2.6.x x86 64-bit (libc 2.7)
• FreeBSD 7 x86 32-bit
• FreeBSD 7 x86 64-bit

You can grab it from the VLC UnRAR plugin page. All binaries have been tested and should work fine (the wide range of different Linux installations makes this platform especially hard to support with binaries).

A big thanks to Pontus Fyhr who provided a shell on his Intel mac which allowed me to build an Intel version.

Source code is of course available as well if you want to attempt to build it yourself. I’ll gladly host third party builds for other platforms.

The FreeBSD Diary and Riseup labs describe a way to anonymize the first “received from” header with usually contain the IP-address of the computer the mail was sent from.  This information is removed by taking advantage of the “Authenticated sender” and the header_checks directive in Postfix.

The “Authenticated sender” is added when a user has been authenticated by the MTA through SASL and the directive smtpd_sasl_authenticated_header have been set to yes.  The header_checks directive takes a file containing a regular expression which rewrites the header data and removes sensitive information.

This all works well – with IPv4. The regular expression posted on the pages mentioned above does not take IPv6 addresses into account, I modified it slightly to accept both IPv4 and IPv6 addresses.

/^Received: from (.* \(\[?[-._[:alnum:]]+\]? \[([\.0-9]{7,15}|IPv6[\:a-fA-F0-9]+)\]\))(.*)
\(Authenticated sender: ([^)]+)\)(.*)(by mx1\.example\.com) \(([^)]+)\) with (E?SMTPS?A?) id
 ([A-F[:digit:]]+)(.*)/ REPLACE Received: from smtp-auth.example.com (smtp-auth.example.com
 [127.0.0.1]) (Authenticated sender: hidden)$5$6 ($7) with $8 id $9 $10

Note that this should be one single line.

Put this in a file, for example /usr/local/etc/postfix/obscure_smtp_auth and add the following to your Postfix configuration (assuming you have SASL working).

header_checks = pcre:/usr/local/etc/postfix/obscure_smtp_auth
smtpd_sasl_authenticated_header = yes

The first header will now be rewritten, for both IPv4 and IPv6 clients and will look something like this.

Received: from smtp-auth.example.com (smtp-auth.example.com [127.0.0.1]) 127.0.0.1 (Authenticated sender: hidden)
	by mx1.example.com (Postfix) with ESMTPSA id 3677033C6F
	for &lthostmaster@example.se>; Wed, 10 Dec 2008 16:31:51 +0100 (CET)

instead of

Received: from [IPv6:2001:xxxx:xxxx:xxxx:xxxx:xxxx:fedd:7914] (unknown [IPv6:2001:xxxx:xxxx:xxxx:xxxx:xxxx::fedd:7914])
	(Authenticated sender: someuser@example.com)
	by mx1.example.com (Postfix) with ESMTPSA id 3677033C6F
	for  &lthostmaster@example.se>;  Wed, 10 Dec 2008 16:31:51 +0100 (CET)

UUID (Universally Unique Identifier) is standard (part of ISO/IEC 11578:1996) to create “universally unique” identifiers to identify objects within a system or across system boundaries. The identifiers are 128-bit in length (that’s 16 bytes) and while there really is no way to guarantee global uniqueness the probability of colissions are very small both thanks to the number of bits and the way the identifiers are created.

The UUID generation algorithms are specified in RFC4122 and I’ve created a static PHP class that implements version 1 which is time based UUID, version 4 which is truly psuedo random UUID and version 3 and 5 which are named based UUID, using either MD5 (version 3) or SHA-1 (version 5).
Read the rest of this entry »