Modern email is actually multiple things in one system (mailer timeouts edition)

June 10, 2012

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.)

Written on 10 June 2012.
« Rethinking when your mailer sends 'not-yet-delivered' warning messages
The anti-spam implications of email being multiple things in one »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 10 00:29:56 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.