4 ms·
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-
by Piskvorrr 2y ago
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)
- enrico204 2y agoActually, 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 :-)
- deleted 2y ago[deleted]
- Quekid5 2y ago> 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.
- Piskvorrr 2y agoYup. "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.