2015-11-02
When setting up per-thing email addresses, make sure you can turn them off
One of the reasonably good weapons in the war against spam is never giving companies your real, core email address but instead creating different individualized email addresses for each place that requires an email address from you. When email addresses inevitably leak or get abused, you can immediately finger the culprit simply by what email address the crud is coming in to. If you start getting spam email to 'you.vendor1@...', well, you know who to blame.
There are a lot of ways to do this, depending on exactly where you have your email; some email providers let you add arbitrary suffixes to your email address after a special character, for example. But however you do this, there is an obvious but important feature you should try to have if at all possible: you should be able to turn off such addresses. Generally such turned off addresses should be rejected during the SMTP transaction, although in some circumstances you might want to turn them into spamtraps instead.
The reason why is pretty straightforward. As I can say from personal experience, after a while at least some of your addresses will become so contaminated that the spam they get is no longer at all interesting. Once an address gets leaked badly enough that the advance fee spammers and the phish spammers and so on get their hands on it, well, there's no end to them.
(I don't recommend that you immerse yourself in the (anti-)spam world, not unless it's your profession. Trying to track advance fee fraud and phish spam is an endless task.)
Most systems for individualized addresses can probably already do this, but if you're building one (for yourself or for a general population), remember to include this. It may take some extra work, but you'll thank yourself in the long run.
(The simple approach is to make the address not exist any more, so it's rejected at SMTP time the same as any other nonexistent local address. The more advanced one is to still reject at SMTP time but to keep track of things like how many attempts to mail it there were recently and so on, and let people see this. Although, honestly, I'm not sure how many people will really care about that. You probably do want to keep track of old turned off addresses so that people get a warning if they're recreating them by accident.)
Status reporting commands should have script-oriented output too
There's a lot of status reporting programs out there on a typical systems; they report on packages, on filesystems, on the status of ZFS pools or Linux software RAID or LVM, on boot environments, on all sorts of things. I've written before about these programs as tools or frontends, where I advocated for writing tools, but it's clear that battle is long since lost; almost no one writes programs that are tools instead of frontends. So today I have a more modest request: status reporting programs should have script oriented output as well as human oriented output.
The obvious reason is that this makes it easier for sysadmins to build scripts on top of your programs. Sysadmins do want to do this, especially these days where automation is increasingly important, and parsing your regular human-oriented output is more difficult and also more error-prone. Such script oriented output doesn't have to be very elaborate, either; it just has to be clear and easy to deal with in a script.
But there's a less obvious reason to have script oriented output; it's much easier to make script oriented output be stable (either de facto or explicitly documented as such). The thing about human oriented output is that it's quite prone to changing its format as additional information gets added and people rethink what the nicest presentation of information is. And it's hard to argue against better, more informative, more readable output (and in fact I don't think one should). But changed output is death on things that try to parse that output; scripts really want and need stable output, and will often break if they're parsing your human oriented output and you change it. When you explicitly split human oriented output from script oriented output, you can provide both the stability that scripts need and the changes that improve what people see. This is a win for both parties.
(As a side effect it may make it easier to change the human oriented output, because there shouldn't be many worries about scripts consuming it too. Assuming that you worried about that in the first place.)
(This is the elaborated version of a tweet and the resulting conversation with Dan McDonald.)