Sending Mail from a locked Mac?

Hi, I have a Xojo program that is otherwise working that is capable of sending eMail automatically when a specified time is reached. It appears to send OK in all cases except when password protection is enabled. That is, it sends OK if the screen is active, and it sends OK when the screen is sleeping, but it does not send once the password requirement of the screen sleep activates. In that case, it doesn’t send the message until you log back in and you send a message manually. That is, the message is apparently queued for sending, but not sent until some other mail activity occurs.

Does this make sense to anyone and is there a fix?

Note I’m using SMTPSecureSocket



That is, difficult to do.

I have a really really bad hack idea for a fix. Prevent sleep with caffinate. Your app will need Full Disk Access for this to work. If you don’t have an interest in adding it to your app, there are existing apps that implement the same thing: Caffeine - IntelliScape Solutions

To clarify, there are a few different settings with sleep, password, and screesaver timeouts.

  1. Screensaver is running: System Preferences / Desktop & Screen Saver / Screen Saver: “Show Screen Saver after ____ minutes”
  2. System Preferences / Security & Privacy: “Require password ____ minutes after sleep or screen saver begins”
  3. System Preferences / Battery / Power Adapter: “Turn Display off After _____ minutes”
  4. System Preferences / Battery / Power Adapter: “Enable Power Nap while plugged into a power adapter”

These settings are complicated, and you can set some nonsensical values (e.g. having the Display Sleep before the Screen Saver activates).

Can you clarify your settings?

When does SMTPSecureSocket work:

  • When in State 1, but State 2 has not been reached?
  • When in State 2?
  • When in State 3 (if so, is State 4 set or not?)

(Also: version of macOS problaby matters as well)

caffeinate -u prevents all of that because that’s what it’s for. The effect is like moving your mouse a pixel each second (but that’s not actually how it works). Screen stays awake and out of password mode.

Like I said, really really bad hack idea


Perhaps such as timer would be more appropriate in a web app, since it will never sleep.

Or a console app uploaded to a server.

1 Like

Hey Mike, thanks for the interest.

Works in situation similar to 1, except I normally start the screensaver with the hot corner
Fails in situation similar to 2, where the require password time has passed

3 and 4 don’t apply

This is an old Mac Mini (early 2009) with MacOS 10.11.6 … I’m practically sure it used to work and may have have broken without my noticing after an upgrade.

The program is supposed to notify my family if I don’t interact with it daily.



AFAIK this is for “Security” reasons, apps are limited to what they can and cannot do when the screen is off and when the screen is locked.

I do not know of a list detailing what and with Apple PJ, you’re not likely to get one as they probably change their minds every five minutes.

App Nap is also applied during a screen off session, which reduces the amount of CPU time your application is given.

I would think that this one is the most appropriate option to disable.

Use cron to schedule your task (crontab is a UI you can use)

You can schedule the computer to wake just a minute or two before your cron task in Preferences >> Energy Saver >> Schedule.

That SHOULD work but I haven’t tried it.

Thanks Sam,

Pretty much my thinking. Of course I don’t want the computer completely unsecured when I’m out (or lying unconscious on the floor, but maybe that wouldn’t matter :slight_smile:

I have fooled with options to suppress the reduction of CPU time allowed, though I forget why now :slight_smile:


Ahh, now we’re talking! I vaguely recall seeing something about this in the past and agree it might work. I’ll look into it and let everyone know.



So I’ve been thinking about this for a while, especially as I’ve been doing a lot of researching into Mac sleeping habits for the last 6 months.

I suspect the way in which this could work (and even if the Mac goes to sleep) is to create a privileged helper that is constantly running (using something like launchd or coreduet). Because this helper was launched with admin permissions, I would expect it to not have the same restrictions as a normal application.

The complication comes from that most of the Apple privileged helpers identity as XPC services. This may or may not be possible from Xojo, they also require encrypted communications between the GUI and helper (XPC). Now in theory it should be possible to create a normal helper and have the OS elevate it’s privileges, you could also use your own encryption methods for exchanging configuration data over IPC or shared memory, heck even using NSUserDefaults. However as this helper permanently has admin privileges, you need to be careful that it doesn’t become a vehicle used to hijack your computer.

Apple considers this much safer than having a normal application run some code in a time limited privileged block, maybe it is, but I don’t feel that it is.

There is private API that an application can use to schedule a DisplayWake.

Another thing: make sure you have Power Nap enabled

Here is a nice article on what Power Nap actually lets the Mac do - it’s a lot:

Addendum 2:
Even if you get the machine to wake on it’s own, unless you disable the password requirement, it will still be “locked”.

So my suggestion goes as follows.

  1. Create a helper application in Xojo that either sends a fixed message or has a secure method for obtaining a message to send.
  2. Utilize the deprecated (but still working) Authorize classes (MBS has these and there’s probably an API 1.0 example out there). To request authorization while the machine is unlocked, store the authorization token. You’ll need to enter in your account password.
  3. Have your application determine when it is the correct time to send the message (it should still fire when the Mac is asleep thanks to PowerNap (PowerNap runs once an hour on Intel and 3~6 times an hour on M1). Then use the authorize token to launch the helper with privileges to send the message.

The above is untested and may not even work, but it’s what I can see you can do with the least amount of work.

3a. If needed, it should possible using private API to create a DisplayWake power management assertion that will wake the screen (like it does to handle Notifications). Once the helper has sent the message, timed out or encountered an error, you release that assertion and it should go back to sleep.

A private API that is not reserved to Apple? Things are getting more fair! :thinking:

You should be fine as long as you don’t intend for your application to last (who does with Apple’s rabid pace of change) or to distribute it via the Mac App Store (you’ll get into trouble for using Private API).

I always thought private APIs where not documented, thus hard to discover. I’d be happy to use them, but I first have to know them. :slightly_smiling_face:

Apple have a lot of code posted over at their “Open Source” portal. Source Browser

I ended up there because I was looking for values a public API returns, which was only documented on their “Open Source” site.

1 Like

What about pmset?

[pmset = power manager settings]

In combination with cron it should work

Terminal → “man pmset” to get the “latest” documentation.