Re:Delay email delivery with Postfix for a relaxing weekend
by Piskvorrr on Monday April 22, 2024 @08:59AM
(#40113937)
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)
Re:Delay email delivery with Postfix for a relaxing weekend
by enrico204 on Monday April 22, 2024 @09:15AM
(#40114041)
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 :-)
Re:Delay email delivery with Postfix for a relaxing weekend
by Quekid5 on Monday April 22, 2024 @05:16PM
(#40120926)
> 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 [email protected]' 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.
Re:Delay email delivery with Postfix for a relaxing weekend
by xorcist on Monday April 22, 2024 @06:03PM
(#40122460)
This 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.
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)
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 [email protected]' 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.
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.
(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.