2009-08-12
Undo is sometimes not good enough
There is a tendency in programming to consider any spiffy new general feature, such as a good infinite undo system, as the way to deal with many of your program's problems. This is often a mistake, and undo makes a good illustration of why.
(It's easy to see how this happens; you have this powerful system that you've invested a lot of effort into, so it's natural to apply it on as much as possible. And programmers really like general solutions, because they have an appealing clarity and simplicity.)
Consider a non-destructive photo editor with a good undo implementation but where there is no way to turn a photo modification off; instead, you are supposed to just undo it if you don't like it. Now imagine that you are working on a photo: you make a modification (say darkening the shadows a bunch), make a whole bunch of further modifications, and then decide that maybe dark shadows aren't the right thing after all and you'd like to see how your picture looks with normal shadows.
Well, now you have a problem. Yes, you can undo the dark shadows (the system has infinite undo), but in order to get there you will have to reverse all of your other modifications. Among other things this is self-defeating, because you can't see what the picture looks like with your other modifications but with normal shadows.
(Technically you can; you just have to revert to normal shadows, remember and carefully re-do all of your other modifications, and then at the end apply the dark shadows modification. Right now you should be having version control flashbacks.)
The problem with undo here is that it is inherently time-based, and thus it is imposing an artificial ordering on something that is unordered or close to it (as the user sees it). This doesn't make time-based undo bad (sometimes the user really will be thinking that way), but it does make it insufficient. Undo cannot be the answer to all of your problems, even though it's a nice general feature.
One thing your mail-sending system should do
If you are for some reason absolutely forced to have a system that will
send email to user-entered addresses (given the principles of modern
email this is not a good idea,
but let's imagine that your management forces you), one of the things
that you should absolutely do is make your system so that it won't send
mail to certain user names. Spamming people is one thing; spamming
abuse
, postmaster
, noc
, security
, and any number of other
administrative user names is just carelessness.
(You may be able to guess what our postmaster alias got today, although it was probably actual spam faking the 'someone requested you be sent information' bit.)
The case for vacation autoreplies is somewhat weaker, but I think that
they should definitely not auto-reply to at least postmaster
. If you
can manage it, the best thing to do probably is to not auto-reply to any
administrative address that is not at your local domain. Your local NOC
or security people might care that someone is not reading their email;
the odds that a NOC elsewhere cares is, well, relatively low.
(These days, postmaster
is not even an administrative address; it is
a system address that is not used by humans, much like daemon
. If you
are lucky, someone reads email sent to it, but no one sensible sends
email from it any more. Addresses like noc
and security
are still
real administrative addresses, in that real people may send email from
them.)
And on a side note, putting the IP address that submitted the web form
into your auto-sent-out email message does not make your email any less
spammy or abusive, or cause people to react any better to it. That
particular well has been thoroughly poisoned by spammers (who forge this
information in the hopes of distracting people). However, if you are
going to do this please insert the same information into the message
headers in some relatively standard format, like X-Originating-Ip:
, so
that automated systems can pick it up and do something with it (although
you should already be doing obvious things like not allowing SBL-listed
IP addresses to send out email).
(As a tip to would-be spammers, try to make your forged IP addresses come from actual allocated IP address space.)