sjh - mountain biking running linux vegan geek spice - mtb / vegan / running / linux / canberra / cycling / etc

Steven Hanley hackergotchi picture Steven
Hanley
About

email: sjh@svana.org

web: https://svana.org/sjh
twitter: https://twitter.com/sjhmtb
instagram: https://instagram.com/sjhmtb

Other online diaries:

Aaron Broughton,
Andrew Pollock,
Anthony Towns,
Chris Yeoh,
Martijn van Oosterhout,
Michael Davies,
Michael Still,
Tony Breeds,

Links:

Linux Weekly News,
XKCD,
Girl Genius,
Planet Linux Australia,
Bilbys,
CORC,

Canberra Weather: forecast, radar.

Subscribe: rss, rss2.0, atom

←November→
Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

←2024→
Months
Jan Feb Mar
Apr May Jun
Jul Aug Sep
Oct NovDec

Categories:

Archive by month:

Fri, 13 Jun 2008

Interest in data from an email spike - 13:56
A few minutes ago in my work email I saw an email appear from the ACT NTEU division. The surprising thing about this email was they attached a 47 MB file to the email (they really should have put a link to it and said it was a large download). Sure if you are at work the size does not take long to download, however it is rather bone-headed for any members to be given an email that size at any other location. (once expanded with the attachment encoding it becomes a fair bit larger anyway).

I can not find the department NTEU person to learn if there are any numbers on how many staff on campus are actually union members, nor can I get hold of the campus wide email system admin people so I can not predict how much this hit storage and network load on the email systems campus wide. I could do some analysis on the department email server, though I am not sure if that would provide much insight. As I suspect there are a fairly large number of union members on campus and they all will have received this email as it is valid email and will have come in through the spam filters.

[/comp/email] link

Wed, 05 Jul 2006

The pungent smell of spam - 08:44
It is obviously true that spammers really do find you anywhere, today I received spam to my palindromic ua.di.hjs@sjh.id.au email address. It however only received a spam assassin score of 3.5, ahh well.

[/comp/email] link

Mon, 27 Mar 2006

Palindromic email address - 15:12
I was just sitting here wondering, I do not think I have ever seen someone use a palindromic email address, such as gro.anavs@svana.org. So there is no real point to it but I thought, for the heck of it I may as well add a palindromic email address to one of my domains. ua.di.hjs@sjh.id.au.

I guess one of the reasons not to is that is harder to type/remember than a normal address such as sjh@sjh.id.au.

[/comp/email] link

Tue, 01 Nov 2005

500 Mile Email Limit - 22:19
This is cool, freaky but cool. This story of a sysadmin trying to find out the cause of a email fault reported by the statistics department claiming email would not deliver to locations much more than 500 miles away.

Reading it, by the end it makes perfect sense, but half way through I was going through the same thoughts he must have been, wtf is happening sort of thoughts.

[/comp/email] link

Tue, 03 May 2005

Random Ani sig thing - 15:13
I previously mentioned a plan to have random signatures in my email using quotes I selected from all Ani Difranco songs. As lca is now over and I do not feel the need to advertise the conference in my signature I thought it was time to finish implementing this. (after all only about one hour was required to finish it)

The perl code may be found here and the source data is this files of quotes. It is not particularly difficult to change the code to use a different data source and different thing to print. As for the code, it would be pretty easy to implement a random selection of a quote every time the program runs. My ideal implementation however uses each quote from the file once until it runs out then starts over again, the same quote can not appear twice in a row.

To do the easy only random implementation I would only need the read_quote_file, serialise_quotes and remove_random_quote functions (it could in fact be simplified far more than this too). So I added command line options (give it an alternate data source, and alternate cache file, an alternate static sig content file, a unique option and a help option). Run as is it uses the default filenames that I set in the code and sits out a random quote.

For my usage the unique option maintains a cache of quotes that diminishes every time the program is run with the -u option. I used Data::Dumper to store the cache, messy and hackish but really easy to do. Anyway pretty basic code, did not take long to implement, and sure it can be simplified a lot (lets hope it does not get out of hand (on the recursive mkdir case, Tony removed a few more characters from Jeremy's example, maybe he should blog about it)) but it works and passes the test case I created for it (small files, missing files, running a thousand times, using various options, etc) though I did not bother making it handle bad input data correctly, oh well no matter.

Getting back into geeky things lightly.

[/comp/email] link

Wed, 22 Dec 2004

ACAP for data access appears difficult - 20:50
In response to my post suggesting address book data be placed in an IMAP folder for easy access from any IMAP client. Brad pointed out the ACAP effort. Admittedly I noticed this rfc on the imap rfcs page when I glanced at it earlier, I did however ignore it as it looked complex. Now looking closer I think I was right it is complex.

About two years ago when a vulnerability in the default implementation of ASN.1 was discovered, almost every appliance or library using it was found to be vulnerable. Although many important protocols (SSL, LDAP, SNMP, etc) use ASN.1 no one had bothered reimplementing it due to the huge size and complexity of the standard. The ACAP people say their protocol is supposed to fill "niche somewhere between a full-blown directory service, a file system, and specialised single-service protocol support".

I still think it is too complex, if you think about basic rss and how much it has taken off, there is no real formal protocol or XML dtd, or anything, rss is simple to implement on both client and server end and it tends to work using standard libraries and tools. I did a CPAN search for ACAP, there was nothing remotely usable available in CPAN to speak ACAP, nor was there a Debian library (apt-cache search acap) or something to make it easier. If you have an IMAP client already however, there are a bunch of vCard libraries in CPAN and Debian, the same applies for the other stuff (email with vCard mime attachments) in Bill's suggestion for an address book in IMAP.

The other thing is I have never seen any mention of ACAP support in a feature list for an email client. (though I have not looked explicitly for this)

[/comp/email] link

Address book storage in an IMAP folder - 17:52
Talking with Bill Clarke last night at work about IMAP issues (I was doing work on more features and stuff for our new email system at work) and he made what I thought was a pretty bloody good suggestion. One of the problems with IMAP storage of email, is though you can access your email from anywhere, you do not have an associated address book accessible from anywhere in all email clients that support IMAP.

Bill's suggestion though simple and not some sort of IMAP extension or anything, to me appears elegant and useful. Store address books in a folder in your IMAP mail storage area. I thought, that sounds neat, use some common format such as vcard attachments to emails. So the folder, could be called anything and store an email per vcard file. The email client could be told to use the IMAP folder named "whatever" to get its address book information. Now all we need is someone to write a thunderbird extension and a squirrelmail extension to do this and we will be set.

I did look around google a bit and glance through the IMAP rfcs and could not see that anyone had done anything similar yet, of course I may have missed it. David Gibson has talked about plans to make a better mail retrieval protocol than IMAP from time to time, to get around problems such as the need for tools like offlineimap (and may I note, how cool is it that this is hosted on gopher). David may have thought of some way to add useful information to his protocol, however nothing is implemented yet so who knows.

[/comp/email] link

home, email, rss, rss2.0, atom