I realise that after I spent many hours setting up Cacti and the Weathermap plugin I did not use 64 bit counters.

Unfortunately this means that pretty much all the gigabit interfaces top out at about 400Mbits as the poller only checked every five minutes and the 32 bit integer is only capable of holding about 4 gig of data - thus:

32bit Integer Interface Counter

At 10Mbs wraps in ~57 mins

At 100Mbs wraps in ~5.7 mins

At 1000Mbs wraps in 34 seconds…

A 64bit Integer Interface counter takes about 5 years to wrap if it runs at 1000GBs…

I became a brief expert (via Google) and found some misleading advice which recommended that I spend a lot of time reconfiguring my RRD files - or just deleting them. Anyway, I did neither and found that just changing them all from plain to 64 bit Counters in the Data Sources section in the Console they happily transferred across (touch wood - I could be writing another post in a while about why I should have just deleted my historical data).

Recently both my parents and parents in law contacted me urgently as important looking letters from CollectionPoint had arrived at our childhood postal addresses. The name "Collection Point Pty Ltd" (www.collectionpoint.com.au/ ) sounded ominous - debt collection - so I was dreading openning the envelopes.

Instead it was saying that CollectionPoint had "found" some missing money in my name - nearly $500. Great no mystery debt - next day I rang them to see what the deal was. They couldn't tell me any details but as long as I was willing to part with $160 collection fee I could keep the rest. Plus give them certified copies of vital identification. Hmm - sounds a bit suspicious and risky (ie they'll have certified copies of my identification plus $160 of my money - bargain).

Anyway, after some Googling I found that other people had received these letters and had recovered their money by using their local government unclaimed moneys online databases:

http://www.publictrustee.act.gov.au/unclaimed/links.html

https://www.e-business.sro.vic.gov.au/eBusiness/UnclaimedMoneys/faces/searchForm.jsp

I found my money in Victoria - didn't need to bother with CollectionPoint at all.

I'm guessing that CollectionPoint must trawl these databases and have some correlation system with electoral roles and phone books to generate the letters which go out. I suspect others have come to somewhat greater grief with them too:

http://www.consumeraction.org.au/downloads/MR-CollectionPointwarning030709.pdf

After a year or so of struggling with generation 1 of the Samsung 30G SSD - I decided to upgrade it to an OCZ Vertex. While the first order delviered a nearly DOA unit - the warranty claim delivered a fully working SSD. 60G is enough for me - I can fit on my Outlook Cached Mode OST file - as well as my Google Desktop database.

While the SSD struggles a bit for 20-30 minutes if I haven't used my Outlook for a week or so (I do have a 10G mailbox in Exchange) it does nicely outperform my old Dell Precision desktop (albeit my new Dell Precision desktop with dual SATA disk does perform perfectly - ie Outlook OST on the main disk - Google Desktop database on the second).

 We've been pretty happy campers with Ironport's implementation of BATV (http://mipassoc.org/batv/) to stop the flood of forged email bounces filling our user inboxes.

 Unfortunately a few days ago things started to go wrong - where BATV generated addresses suddenly became invalid when checked by third party MTA's on our Ironports.

 After some investigation by the Ironport engineers a general notice was posted on Ironport support advising that BATV be turned off until a patch could be released.

 Interestingly (and good for confirmation) after we turned it off, we got a sudden increase in logged jobs from end users complaining about the "sudden" increase in "forged email bounces". We didn't tell them we turned off BATV - too hard to explain (too hard to explain why it's so easy to forge their email address in the first place!).

I recently acquired my replacement work laptop - a Dell Latitude D630 with XP. I decided, since I had the opportunity, to instead of getting the standard spining hard disk I'd get the (much) smaller SanDisk SSD 32Gig "drive". There's a lot of media saying that while it is expensive it's the best performance money can buy. Hmm.

After a few months of usage here's my opinions:

Pro's

* dead silent running (no fan or hard disk noise)
* faster (but not amazing) read access
* slightly increased battery life (although I have forsake the DVD and put in a 9 and 6 cell battery combined - so the laptop is heavy but goes 7 hours with wireless active)

Con's

* the laptop essentially locks up when there is a lot of read/write to large files - eg an 8 gig Outlook 2003 Cache Mode file or a Google Desktop database. This is despite having 4 gig of RAM and 2.6 gig dual core. The SSD is good a read/write on small files - but write to large files and it's not so good. Or maybe it's too good and the system has no resources for anything else while it's doing it. Basically you have to wait for Outlook  and Google Desktop to finish synchronising - about 10 minutes. Maybe I will need to upgrade to Vista and use a flash cache as well.
* running out of space - my theory that I only needed 32G was a bit flawed. I only have 4gig left... without even trying. Maybe I will get the more recently released 64Gig SSD.

The Outlook Cached Mode (or large file) performance hit doesn't seem to have registered with many people yet (there's a few hits on Google from people who have given up on SSDs with Outlook Cached Mode and gone back to spinning disk). 

It took the laptop about 7 days to create an 8 gig cached mode file and for Google Desktop to index it all. 

PS I also found this article shortly after writing this post - wish I saw it before I got the SSD in the first place (http://www.followsteph.com/2008/02/14/solid-state-drive-ssd-review/)

Ironport is keeping us on our toes with their implementation of BATV. Originally when we deployed it we were assured that the BATV tag would remain constant in the MAIL FROM. This would prevent issues with grey listing and mailing lists with use MAIL FROM for authentication.

Unfortunately in a newer version of AsyncOS they have quietly changed that behaviour so it now includes the date as well...

It would have been helpful if they'd log the outgoing BATV tag so we could see what was happening.

 We've been looking at third party SFP and GBIC suppliers to try and bring our optic costs down.

We had good success with getting Agilestar SFP's from the US (http://www.overnighthardware.com) - heaps cheaper than the local resellers (especially with the good US vs Aussie dollar exchange rate). However, as fairly standard with many grey market optic providers, Agilestar has not complied with Cisco's unofficial optics standards - Cisco, in order to prevent simple counterfeiting and greymarketing, does not allow SFPs or GBICs which have identical serial numbers to be present in the same chassis. If they are found in the same chassis the IOS will shutdown BOTH interfaces - which could be disasterous.

As far as we can tell Agilestar has generated serial numbers with a unique range of 1000 - which is fine if you are running chassis of say 4-10 optics. If you run a chassis which has 150-200 optics, then the chances of a serial number collision get higher.

We were able to return the Agilestar SFPs and receive a new range - however we never really got a clear answer as to whether Agilestar just generated another 1000 range of serial numbers or actually have a system to generate unique serial numbers.

As a bold experiement, last night we experiemented cooking Wagyu beef steaks on the weber bbq. Given they were $18 each I didn't want to end up with leather so I did some extensive internet research. Most recipes didn't cook Wagyu in thick steaks - so in the end I found this site http://www.lobels.com/recipe/perfectsteak.htm. 

This did the trick - rubbed thyme, pepper and olive oil into both sides, seared on both sides for 3 minutes/side  on direct heat, then medium indirect heat for another 4 minutes until the red juice arrived on the surface (as the wife likes things well done rather than rare).

The end result was superb - I attempt to reproduce it with scotch fillet (hoping the similar marbled structure would lend itself to a similar result)  the next night but after premium steak it was dense and flavourless...

 

Our domain names (which are quite old) are often used by spammers - who forge them in their unwanted emails. Somtimes our users get one or two a day/month - sometimes in rare cases they get thousands an hour rendering their email address unusable.

Previously it was only the older deprecated domain names which were being forged - a good way to get people to migrate to our (somewhat) newer domain. However, now the spammers are forging our current domain name.

In a previous post, I mentioned we had started to get people to enforce our SPF and SenderID settings - that's fine for those people who do enforce it. However, for the rest of the internet the only option currently available is Bounce Address Tag Verification (http://mipassoc.org/batv/). We enabled this on our Ironports today and once again started to find problems with the implementation of SMTP and related applications elsewhere on the internet (although we are happily dropping thousands of forged bounces each day now!).

BATV changes the MAIL FROM header from my.name@example.com to prvs=<tag>=My.Name@example.com for all mail leaving our mail servers. Any bounces which are returned to our mail servers must have the prvs=<tag>=My.Name format - otherwise we just delete them. This is fine in 99.9% of cases of course. We can change the unique tag as time goes on - in case that is forged too.

The main problem we found was a poorly implemented anti-spam technique of Reverse Address Verification - this is where when we send an email, the remote MTA initiates it's own connection back to our mail server to see if the email address is valid. We're normally fine with this - however deep within the SMTP RFC "specifications" it says that remote MTA's must not change the case of the email address (prior to the domain name). Unfortunately a few of these reverse address verification tools (eg smf-sav http://smfs.sourceforge.net/smf-sav.html*) lower case the email address component which then means our Ironport regards it as an invalid address - ie we send out at prvs=<tag>=My.Name@example.com and smf-sav returns to try prvs=<tag>=my.name@example.com (Ironport says "no such address").

For some places we have gotten them to disable reverse address for our domain, for others we have not been able to find someone to do it and have just not BATV'ed email to their domain. I guess the problem is that Ironport will need to put in some tolerance (ie lower-casing) in a future release - which they have promised to do. But authors of these reverse address verification tools will need to fix their stuff up as well - which is probably pretty much impossible given that most of them are open source and installations untraceable.

Some dodgy anti-spam filters have also been dubious about the BATV-style addressing and marked our emails as spam.

One place refused to accept email which had an = in the email address component (dunno how they every received mailing list emails).

There are some mailing list software programs (eg the OpenVMS ones) which use MAIL FROM for access control. We'll have to white list that - unless they change their mailing list software to become BATV aware. Unlikely.

Still, BATV is doing it's stuff for us.

At work we have recently enabled SPF and SenderID (although we've had SPF records forever - they have not been configured as enforceable - ie they contain a "~"). Our SenderScore subscription required us to have them in the first place - but are now getting more strident to have them set to be enforced. Supposedly Hotmail/Livemail want them enforced too now.

On enabling them both, we had a swathe of user reports of bounce messages from misconfigured mail servers. A number of organisations appear to have multi-hop email delivery - and for reasons only known to themselves check SPF records on the second hop (a common one is people using Exchange and ticking the SenderID box as "that will prevent spam!"). We had to painstakingly contact each remote MTA email admin and try and explain the issue. There was no way we were going to put other people's IP addresses into our SPF record - as suggested by several admins.

Another issue we found were crude distribution lists (eg Exchange and UNIX /etc/aliases style) where our emails were being forwarded on by other hosts. These we left alone - up to the user affected and the administrator of the DL to fix or cope with.