That would have another use, too: hiding your sleep schedule from the recipient. You could write an email at 3:00 AM, set an 8 hour delay, and appear to have regular sleep patterns.
If you wake up in the middle of the night to heed nature’s call, take a moment to leave a voicemail message for your boss. Your message will automatically leave a recorded time-stamp, thus reinforcing the illusion that you work around the clock. This is a big improvement over reality -- that you chugged a beer before going to bed.
at lets you specify dates as day/month/year. All you have to do is make sure the computer is running at that time, which is easy if you do this on your mail server.
I want this so bad. I've looked before, but I can't find this feature anywhere.
But rather than setting delays I'd like to just define a range (say 8am–6pm) during which mail is sent. Anything outside that range would be queued until the next period.
BTW, I thought about similar feature - setting a desired reply date/time on e-mails you send, so the recipients MUA can automatically schedule it in users calendar (and/or remind him of replying you).
As of many people replying they need a feature no one has - here's opportunity of creating a completely new web e-mail system :-).
1) How to build it? (server-based or client-based) and
2) Who's going to pay for it?
It sounds like one of those things that a small number of people talk passionately about but there's not actually any money in making their pain go away. Or maybe -- beats the heck out of me where the payback is.
Client-side this is less than a week on the Microsoft platform -- a month if you want to handle all email clients. Server-side? I think you'd have to pick just one mail host and stick to customizing it.
One of the issues would be turning it off -- you'd have to have some kind of neato keypad test thingy to prevent drunken farts from just clicking the button and sending anyway. That leads me to believe a better design might be client-side.
That's a nice one. Didn't think about that. It's a nice compromise between client and server solutions.
Store-and-forward has another big set of issues though. File sizes and bandwidth requirements are easily non-trivial. In addition, there could be legal issues with keeping the data around for awhile and then forwarding that wouldn't exist if you just piggy-backed on some other app. In a way, it kind of puts you in the league with GMail and the other guys, right?
Maybe it could be a greasemonkey-added "Send later..." button that you have to manually click on every time (to avoid thinking you sent an email, but it was actually put into a queue) along with an input box for delay-time.
When you click it, it could (1) add a unique identifier to the subject, (2) save the email in drafts, and (3) send a message to a server-side app (which knows your Gmail authentication info) with the ID of the message and the time it should be sent. Then at the appropriate time this app logs in, finds message by unique ID, gets rid of said ID, and sends the message.
