2012-06-10
The anti-spam implications of email being multiple things in one
One of the immediate corollaries of there being lots of different sorts of email and there being no reliable way of telling them apart is that different people can wind up basically using completely different flavours of email. For example, some people in your organization may basically never use email for real time conversations, at least not with outside people, while others may need to use it this way all the time. An important consequence of this is that at least some anti-spam precautions on incoming email are intrinsically dependent on the receiver; whether or not they're usable depends on what sort of 'email' the receiver actually uses out of all of the various options.
Let me elaborate on that. I used to feel that anti-spam precautions could be one size fits all, and the main reason to offer users options was because not all of them had been persuaded that our recommended set of options were fully trustworthy and the right answer. This is clearly wrong for at least some anti-spam options; the obvious example here is greylisting, which implicitly uses the heuristic that a new sender can't be sending real time email. This is more or less correct for many people but is also clearly incorrect for some people, who as a result intrinsically can't use greylisting.
(The argument that greylisting advocates might advance here is that someone sending you an email for the first time has no idea how fast you'll respond; only after you respond immediately do things become real-time. This is wrong because it ignores knowledge and expectations that the sender may have from stuff outside the email system.)
Thus our need to offer our users at least some options for anti-spam processing is essentially intrinsic and always going to be there. Because different people may well use email differently, there is no one size fits all set of anti-spam precautions (unless we can somehow find a lowest common denominator of precautions among everyone and then offer only that); different people need different options and we need to offer them the choice.
(This casts an interestingly different light on the question of what options we need to offer; it's not just how people think about spam filtering, it's what they need and want out of email from external people. Since I just came to this realization recently I don't have any answers, just something to think about.)
Modern email is actually multiple things in one system (mailer timeouts edition)
A commentator on on my entry on mailer delay warnings suggested, in response to my view that repeated delay notices are bad partly because after a day the sender isn't expecting the mail to get through soon anyways:
I think the default for many mailers is to warn after one day, and give up after five. Given the above sentence, in addition to a warning after an hour (as you state), it seems that you opinion is that the mail system should give up after 1-2 days.
I actually don't think that this is a good idea (or the right thing).
One of the complications of handling modern email for both senders and receivers is that it has effectively become a whole bunch of applications and communication systems in one protocol, and what's appropriate for one 'flavour' can be wildly wrong for another. While I'm not going to try to do a complete taxonomy, one big split in sorts of email is between email used as a means of near-realtime communication (both for conversations and for notifications) and email that isn't.
(I've alluded to a split in the sorts of email before, but not spelled it out explicitly.)
Most near-realtime email loses its usefulness very fast as it gets delayed. If you're conducting a near-realtime conversation over email and email stalls, either you're going to abandon the conversation entirely or change to another medium (a telephone call, for example). It makes decent sense for the mailer to give up entirely on delivering this email in only a day or two, because after even a day the conversation is almost certainly either dead or over. But not all email is near-realtime email; there's plenty that isn't. That 'slow' email generally remains useful to deliver even after several days of delay, or even many days of delay, so you don't want to give up on it until you need to.
Unfortunately one of the problems in modern email is that there's no good way to tell all of the different sorts of email apart; the best we have on both the sending and the receiving side is heuristics, and they misfire periodically. Since we can't expire all delayed email after only a day or two and we can't really tell apart fast expire email from slow expire email, the only safe thing to do is expire all email slowly.
(How slowly to expire email is a somewhat complex subject that calls for another entry.)