An Email Strategy

Posted in: System Administration

Anyone with an email address has had to deal with spam. Insidious, potentially offensive, sometimes incomprehensible but definitely time wasting spam. It is such a problem that there is a whole industry of software products out there to deal with the spam. Some of these tools can delete the spam straight away, others just tag it and allow you to redirect it to a Spam folder or something similar. But what none of them can tell you is who gave away your email address? Was it that online store you purchased a gift from last month? Did they then sell your email address to a list broker? Maybe it was a co-worker playing a joke that gave your personal address to that porn site?

Wouldn’t it be nice to know who gave away your email address? I certainly want to know.

In addition, unfortunately as good as some of the tools out there are, some spam inevitably gets through. I have given up on email addresses because they had become so riddled with spam that the signal to noise ratio was not worth the effort anymore. My original Yahoo! mail account comes to mind. I want to be able to block as much spam as possible – not tag it or redirect it, I simply want to know nothing about its existence in the first place.

So this is how I manage my email and deal with spam.

Firstly I purchased my own domain name and I set up an email server to host the email for that domain. Even the most basic Linux hosting plans will be more than enough for this purpose.

Next I set up just one real account on the email server. I then configured the server to redirect all of the email sent to that domain to that one real account. This is often called a catch-all account.

Now whenever I need to provide an email address for something, I use a unique one-off address. For example, when I signed up for Netflix, I used netflix@mydomain.com as the email address for my account. Whenever Netflix sends me an email at that address, it still ends up in my Inbox because of the catch-all account. l also know that if I start getting spam email being sent to netflix@mydomain.com then I need to have some harsh words with Netflix (thankfully this has not happened with Netflix).

If you implement this strategy, you’ll be surprised how many of these one-off addresses you end up creating. So to keep things organized (and so I do not forget who I gave the address too) I try to map these addresses to the domain names of the website or the company I am giving them too. This however, will raise some eyebrows from time to time. When the car salesman at the BMW dealership asks for your email address and you tell him it is bmw@mydomain.com you will almost certainly get a strange look.

OK, so now I can give out unique (traceable) email addresses to companies and websites when they ask for them. If I start getting spam being sent to a specific address, I know who sold me out. It also means that the email address that my personal friends and family use is kept reasonably secluded and not plastered all over websites and in databases all over the planet.

Now what do I do if the spam being sent to one of these unique email address gets out of hand? Easy, I just block receiving email for that address on the server. Any email sent to that address will bounce back to the sender with a message telling them that the account is no longer valid. I never see the email, I am never even aware of its existence, I never waste time downloading it to my phone or laptop. Perfect. In addition, the rest of my email is not affected, it still all gets through.

In my environment I run Sendmail as my mail server. Configuring Sendmail to completely block certain recipient addresses is very simple. You will need to edit the file /etc/mail/access which is a simple text file – if it does not exist, you can create it. In this file, you will need to add a line for each address you want to block. Here is an example

To:bmw@mydomain.com REJECT
To:vistaprint@mydomain.com REJECT

Sendmail will reject/bounce any inbound message sent to either of these 2 addresses. In my actual file I have about 15 addresses total being bounced currently.

Once you have edited the access file, you have to turn it into the database format that Sendmail expects. This is also easy to do.

$ cd /etc/mail
$ makemap hash access.db < access

That’s it. You don’t even need to restart Sendmail, the settings take effect straight away. Anytime you need to start rejecting another email you just add another line to the access file and regenerate the database.

Now, in the spirit of full disclosure, I admit that I do still get some spam. This is spam that is being sent to addresses that are legitimate and which I do not want to block. But I do know that the number of spam messages I do see versus the number that are getting bounced is slanted heavily in my favor – something like 1 or 2 per day get through versus 1 or 2 hundred that are getting bounced.

Let me know if you have any other ideas for taking better control of your email.

Are you hiring a hacker, a coder or an engineer?

Posted in: Software Development Team Leadership

There are many types of developers who work in the IT industry. When it comes time to hire a new developer it can be tough to figure out which kind of developer you are interviewing. When I do an interview I try to place the candidate in one of 3 categories – hacker, coder or engineer.

The Hacker

How to spot one:

  • Has been coding since they were 12, but have no notable credentials (no college degree, no professional certifications etc)
  • Believes all problems can be solved with some kind of “script”
  • Is unable to answer questions related to emerging industry trends
  • Appears uninterested in training opportunities
  • Their answers will be 1 or 2 words in length and no matter how much you coax them, they will not expand on them
  • Has an unhealthy fascination with the game World of Warcraft, to the point it will probably affect their performance as an employee

When to hire one:
Hiring a hacker is always a gamble for a development role. Often they make better sys admins than actual developers, since they are quite comfortable working all-nighters in dark rooms (as long as there is a supply of energy drinks and pop-tarts). They can also thrive in a QA role where automation of repeating tasks is a key skill (hackers also tend to like to break things).

When not to hire one:
A Hacker can become a rogue and distracting element in your development team. If you are looking for a team member that will have a focus on quality and meeting deadlines, a Hacker is not for you. If you want an employee that will work a regular schedule that doesn’t include them showing up at 11am looking like they have had no sleep, then a Hacker is not for you. These are the kinds of employees that you find out have been running a personal ecommerce site piggybacked on one of your corporate servers for the last 6 months.


The Coder

How to spot one:

  • Probably has a degree, but has no professional credentials (no certifications etc.)
  • Can answer common programming questions, maybe even understands Object Oriented principles, but probably struggles to answer big picture architecture questions
  • Probably cannot answer questions related to emerging industry trends
  • Doesn’t have a strong interest in getting training, attending conferences or expanding their skills in general
  • You will have to work to get them to expand on their answers beyond 1 or 2 words
  • Their references are probably positive
  • They like to play World of Warcraft at least a couple of nights a week

When to hire one:
A Coder is usually a good hire if you are simply looking to increase your development bandwidth. They will be able to contribute to a project in terms of pumping out code, but will need a solid design or requirements to follow closely. You will also need to make sure there is an Engineer close by to keep an eye on them.

When not to hire one:
If you are looking for a people leader or a technology leader, a Coder is not for you. Also don’t expect to be able to have a philosophical discussion about the state of the software industry with a Coder.


The Engineer

How to spot one:

  • Has a degree, maybe even an advanced degree, but is not a new graduate. To be an Engineer, some real world exposure is needed to shake off the bad stuff they learned in college and develop their own ideas.
  • Has a strong opinion about industry trends
  • Asks questions about training opportunities and budgets for attending industry conferences
  • Can name some tech authors they like or industry luminaries they agree with
  • Asks questions about what development processes and tools are used at your company
  • May not be able to answer every low level code or syntax question you throw at them (this is not a concern, Engineers are usually thinking at a higher level and know how to quickly find the documentation about the API they want to use if they need to)
  • Is reasonably articulate and their answers are usually more than 1 or 2 words in length
  • The interview will be much more of a conversation than an interrogation
  • Are aware of the game World of Warcraft, but don’t seem to have time to play it because of all of the tech books and journals they are trying to keep up with

When to hire one:
In general, the Engineer is the employee you are looking for. Just like in sports where you have franchise players, a good Engineer or two on your team can make or break a whole company. They are going to push the envelope in terms of the pace of development, introducing new tools, technologies and ideas and also the basic way in which the team operates. If you are working on projects that require novel solutions to be created, you will need an Engineer, as a Coder will not bring this kind of skill to the table. Also if you want to be able to increase the number of tasks you can delegate, the Engineer is for you.

When not to hire one:
Depending on the project you are working on, an Engineer can sometimes be a bit like having a sledgehammer in your hand when all you want to do is tap in a small nail. If you are working on small simple projects, or the work is generally a matter of taking a set of pre-defined requirements and pumping out a solution that requires little thought, then an Engineer may become bored quickly and you will find them moving on soon. Also expect an Engineer to have a solid idea of how things should work to be effective. Do not expect to mold an Engineer – you should be hiring them to help evolve your team, not to persuade them to the way you do things now. Additionally an Engineer will be aware of the going pay rate for someone with their skill set, so do not expect to get them cheap.


Conclusion

Not all developers are created equal. When you have an open requisition for a new developer, be aware of what kind you are truly looking for. If you need an Engineer, but only have the budget for a Coder, you need to take a hard look at what the longer term implications for your team are if you don’t have the Engineer. Once you are in the interview, make sure you have questions set up to help you quickly determine what kind of developer you are talking to. And never forget what an unusual amount of influence the World Of Warcraft will have on your hiring decisions!