Skip to content
A scene from Ireland

Opinion

  • in Opinion
  • 2 min read

Getting Organised

I often get the feeling that I am thrashing - lots of little things to do, plenty of interruptions, stuff gets done but it doesn't seem to get done as efficiently as it should. I spend to much time trying to decide what to do next.

So I recently (well, a few weeks ago now) realised that it was time for something to change.

Since then, I have been planning to do one thing each day. Sometime two if the second one was small, but normally one.

If I get an interruption that cannot be dealt with immediately, I schedule it in so that it has it's day, a few days hence.

This has been working REALLY WELL.

  • Firstly, there is the feeling of being in control - I have a plan.
  • Then there is the feeling of being productive. I can cross something off each day.
    BULLET - It also means that I know what to do first thing - I have already allocated something to do, so I get stuck in and do it. BULLET - Sometimes things don't take the whole day, and I can do something that was scheduled for a later day and so get ahead of my plans. This doesn't happen often, but it feels good when it does. BULLET - It means that the less-urgent things still get attended to. Maybe not often, but at least sometimes. I have been using my work-at-home day to work on my filesystem (which I really should create a page about). I haven't spent any time on that for nearly a year .

On the whole, I am very pleased.

  • in Opinion
  • 2 min read

Address rewriting

We want to re-write addresses and recognise rewritten addresses.

There are two situations where we want to re-write addresses.

BULLET - If we trust the source of a return address, we want to re-write it when sending the mail to be signed and to look like it comes from us. If it really comes from a local domain that we aren't the only MX for, then rewriting isn't appropriate. I probably need to refine 'local domain' into those that we control completely and those that we spool and forward mail for. BULLET - When we are forwarding mail through the virus checker, we want to re-write the sender and recipient addresses. This rewriting should be different from the other rewriting and should be transparent to the rest of the mail system.

Recognising re-written address needs to happen for all incoming mail - the to address can always be encapsulated.

Also, we want to recognise special recipient address that are coming from forwarders. e.g. if the localpart contains an equals sign, then we check if the domain which follows that equals is a reliable source of the mail.

The rewriting of return-path should keep the original domain for local domains, and use cse.unsw.edu.au for all others.

In the first case we can use SES= to flag the address.

For others, SRS= seems better.

For virus re-writing, VRF and VRT for the virus from and to addresses.

If we get mail from a VRF and to a VRT, we accept it. If it is to a VRF and from <>, then it has to go to postmaster. Otherwise we reject it.

  • in Opinion
  • 1 min read

SPF-Received tagging

smtp-recv should tag all arriving email with SPF-Received.

If the mail is to an address (and only one address) which contains an equals sign followed by atleast one period, we use that domain for SPF checking.

Otherwise if the mail is from <>, then we assume FAIL if the to address wasn't encapsulated, and PASS if it was.

Otherwise we perform an SPF check on the MAIL FROM address.

  • in Opinion
  • 1 min read

Authenticate incoming mail

All incoming mail that claims to be from a local address must, eventually, be authenticated. I.e we must have some trace of who sent it.

There are three ways to be authentic:

  • Come from a local trusted machine that supports identd
  • Come over SSL with a username and password
  • Come over SSL with a certificate that we have signed

In general, any authenticated user may use any address. We need to be sure that more widely accessable users such as w3serv which runs our webmail service cannot be abused.

The first two options are already available. We need a system for handing out signed SSL certificates. The common name should be something like mailfrom:neilb@cse.unsw.edu.au. This still allows mail from any local address, but it identifies the source.

Once this is inplace and there are some FAQs that describe it, we need to start identifying people who aren't being authenticated and need to be. Some simple logging in the smtp receiver should achieve this easily.

When the log shows that sufficiently few people (preferably none) are not authenticated properly, we disable non-authenticated users for external addresses completely. For internal addresses we need to accept them but with an SPF tag indicating probable junk.

Beyond Spreadsheets

It is time that so-called "Office suites" got beyond the spreadsheet.

Spread sheets are a wonderful and powerful idea. I have put them to good use several times. But they are tied to an idea that is no longer relevant - the idea from which they got their name.

A spread sheet is basically an infinitely (or atleast indefinately) large two dimensional table of cells. Each cell can do calculations based on values in other cells. This is great for doing calculations on columns or rows or whole tables. This works really well. There is just one problem.

I've never wanted to have an indefinately large table.

  • in Opinion
  • 3 min read

A new sort of HashCash?

One of the many schemes that have been proposed to fight junk e-mail is HashCash.

The basic idea is that a HashCash token is a string which a particular property that make is hard to create, but easy to check if that property is present.

The way you use it is to require that anyone who sends you Email, and who isn't on your whitelist, must include a new HashCash token in the mail item. This proves that they have done a measurable amount of work for the privilege of sending you mail.

The value of this is that spammers, who tend to need to send tens of thousands of emails just to get a few responses, would not be able to afford to generate these tokens and so wouldn't be able to get their mail through to you. On the other hand, individually who want to send you one mail (and hopefully then get onto your whitelist) would have no problem with the cost of generating a hashcash token for you.

One problem with the scheme as proposed is that you need to keep a list of all hashcash tokens that you have received so that a spammer cannot generate just one and use it over and over again.

My idea is to overcome that problem by making hashcash tokens safely reusable.

I want a better EMACS

I'm a great fan of EMACS. I use it every day for reading mail, for code development, and for just about everything involving text files. But I'm really hoping for something better to come along.

The problem is that while EMACS does have a reasonably good mail reader (VM, I use it constantly) and a very useful IDE bits and pieces and even a web browser, none of these applications are really great.

I think the reason for this is that it is really hard to write applications for EMACS.

SPF looks like it is worth supporting

With my Email administrator hat on, I have been looking at SPF lately.

SPF stands for Sender Policy Framework and is a mechanism whereby the owner of a domain can advertise that domain's policy on how it sends mail.

When an MTA recieved mail claiming to be from a particular domain, it can queries that domains policy and then make a determination on how likely it is that the from address is authentic. This information can then be used as input to a local policy on dealing with junk mail.