Delay email delivery with Postfix for a relaxing weekend
enricobassetti.itThis is a nice way to show what you can do with Postfix. But if you actually wanted this functionality, it would be much less error prone to implement this in your delivery agent rather than your transfer agent. For example Procmail or Sieve or whatever you use to filter incoming mail.
(An email system is normally in three parts, a transfer agent that talks to remote systems such as Postfix, a delivery agent that delivers to a local mailbox such as Sieve or Procmail, and a user agent which is what you use to read your mail such as Thunderbird or mutt.)
Just change your filter to change the delivery mailbox to a separate one for weekends. That way you won't risk causing any bounces if you do something wrong.
This would be really popular for sms, especially for mac interface or iphone.
E-mail is, at its core, best-effort, respond-maybe protocol. Implementing "quiet hours as seen in IM", means using the wrong tool.
If you insist on treating e-mail as a medium requiring immediate response, you'll be going into Postfix on weekends to force-flush the queue instead. This is not a technological problem, definitely not one that's solvable through configuration tweaking.
(I mean, sure, it's an impressive exercise in how flexible the sw stack is, but the issue lies elsewhere)
Actually, my idea was to delay e-mails because I don't want to read them during weekends, while I still want to read other e-mails (e.g., newsletters, login alerts). I still open my inbox once per day :-)
> E-mail is, at its core, best-effort, [...]
If anyone expends as much effort at delivery (7 days, usually, with spaced repetition) of anything these days, I'd be seriously impressed.
> Implementing "quiet hours as seen in IM", means using the wrong tool.
Modern MUAs can usually do this sort of thing, tbf.
AFAICT using the MTA is a great way to avoid "can't stop looking syndrome"... I can't see the content of e-mails if all I see is 'rejected email from xyz@foo.bar' in the logs. Ofc, you need to reject them before they enter the queue -- that's the point!
Anyway, I don't particularly begrudge anybody solving problems in a way that works for them.
Yup. "Try as best as you can (to eventually deliver, not ASAP), but if you can't - well, all content in transit is considered ephemeral."
I mean, I do battle with notification-FOMO as much as anyone; if it works, go for it. I would just be tempted to poke at the rejected queue.