Implementing “right to disconnect” by delaying outgoing email?

Posted on by lucas

France passed a law about “right to disconnect” (more info here or here). The idea of not sending professional emails when people are not supposed to read them in order to protect their private lifes, is a pretty good one, especially when hierarchy is involved. However, I tend to do email at random times, and I would rather continue doing that, but just delay the actual sending of the email to the appropriate time (e.g., when I do email in the evening, it would actually be sent the following morning at 9am).

I wonder how I could make this fit into my email workflow. I write email using mutt on my laptop, then push it locally to nullmailer, that then relays it, over an SSH tunnel, to a remote server (running Exim4).

Of course the fallback solution would be to use mutt’s postponing feature. Or to draft the email in a text editor. But that’s not really nice, because it requires going back to the email at the appropriate time. I would like a solution where I would write the email, add a header (or maybe manually add a Date: header — in all cases that header should reflect the time the mail was sent, not the time it was written), send the email, and have nullmailer or the remote server queue it until the appropriate time is reached (e.g., delaying while “current_time < Date header in email”). I don’t want to do that for all emails: e.g. personal emails can go out immediately.

Any ideas on how to implement that? I’m attached to mutt and relaying using SSH, but not attached to nullmailer or exim4. Ideally the delaying would happen on my remote server, so that my laptop doesn’t need to be online at the appropriate time.

Update: mutt does not allow to set the Date: field manually (if you enable the edit_headers option and edit it manually, its value gets overwritten). I did not find the relevant code yet, but that behaviour is mentioned in that bug.

Update 2: ah, it’s this code in sendlib.c (and there’s no way to configure that behaviour):

 /* mutt_write_rfc822_header() only writes out a Date: header with
 * mode == 0, i.e. _not_ postponment; so write out one ourself */
 if (post)
   fprintf (msg->fp, "%s", mutt_make_date (buf, sizeof (buf)));

9 thoughts on “Implementing “right to disconnect” by delaying outgoing email?”

  1. I don’t think that delaying the sending is the right solution. Think about sending emails to different time zones. And even if it is the right time, maybe there is a public holiday in the receiver’s country? Or the other way around: you don’t want to send now, but for the receiver it is a normal workday
    A right to disconnect should be implemented on the receiving side: the mail server still accepts all incoming mail, but only forwards them to the recipients during normal business hours.

  2. @Thomas: I was thinking about delaying being specified per email (e.g. by editing a header), not doing it for all emails. So that would leave space for a default behaviour of “send immediately”.

  4. I implemented this for myself (though using gnus and a permanently-attached client): the details are in a blog post I wrote at the time.

    One observation that I have since then: even though this is implemented at the sending side (by me making a choice when I send a mail, defaulting to delay outside working hours), I have seen a reduction in mail I receive outside working hours, because I’m less likely to be engaged in an active discussion. So it’s been good for me too!

    Christophe

  7. Gnus has this built in, usually you press C-c C-c to send an email, but if you press C-c C-j instead, you will be prompted for when the email should be sent (or how long it should be delayed).

    The configuration needed is:
    ; Activate delayed messages:
    (gnus-delay-initialize)
    ; Remove date, so delayed messages (C-c C-j) don't get a date until
    ; sent :
    (setq message-draft-headers '(References From))
    ; Demon to send queued email every other minute:
    (gnus-demon-add-handler 'gnus-delay-send-queue 1 nil)
    (gnus-demon-init)

  9. Isn’t the right to disconnect a “not expected to check email” thing, as opposed to “not being sent email”? If so, sending mail could be sent without delay and just sit unread in the inbox during the non-work hours, right?

Comments are closed.