Currently, on Windows, E-MailRelay installs itself as a service running as "Local System". According to the documentation, there is no user-id switching on Windows, so the service runs with full system permissions.
To mitigate the effect of potential 0-days, I'd like to run the service with lower permissions - for example, with the built-in NT Service*Servicename* account. I am aware that this means that I'll have to assign appropriate permissions to the log, queue, etc. directories.
Has this been done before? Is this a "supported configuration"?
* If yes, is there a checklist of permissions that need to be set?
* If no, should it work in principle, or are there some known issues that make it not worth trying?
(Should be
NT Service\Servicename
, the backslash messed up the formatting.)That's a good idea. I expect this has been done many times, but I have had no feedback to share with you.
In my (limited) understanding you can set the account used by the service easily enough using the "Services" tool. The emailrelay service is actually a service wrapper that executes the emailrelay server in a separate process, and the account propagates from the service wrapper, on to the main emailrelay server process, and then on to any filter or address-verifier scripts.
If you control the account permissions carefully I am not sure there is much benefit in doing any userid switching as is done on unix, but I am open to persuasion on that point.
What would be the 'output' of this excercise? Perhaps a powershell script to set up a suitable account? I would be happy to help with feedback and testing.
Thanks for the feedback.
I agree that userid switching on Windows probably won't make sense: AFAIK, Windows does not have the "privileged ports < 1024" restriction that requires root on Unix, and you cannot easily do a "user switch without a password" anyway. The idiomatic way on Windows is to run the service itself with a lower-privileged account.
As "output", I guess documentation, i.e. a checklist of permissions that are required, would already be a helpful first step for users who want to harden their system.
I'll do some tests in the next days and report back my findings.
It worked!
I changed the service user to its virtual service account and granted modify permissions to emailrelay.pid, the spool directory and the log directory. Here are the exact cmd commands I used. (To future readers: note that I used a non-standard log directory, you might need to change that path.)
Notes:
C:\ProgramData
and its subfolders, so it's not necessary to assign explicit read permissions toC:\ProgamData\E-MailRelay
.C:\ProgramData\E-MailRelay
directory. That's easier, but it also allows the process to modify its own configuration files, so it's arguably less secure.obj=
in thesc
command line is important. Yes,sc
's syntax is weird.That's really useful, thank you. I'll add that information to the 'running as a service' section of the emailrelay 'windows' document.
Glad to hear that it's useful.
Oh, and thanks for your help and for maintaining E-MailRelay! Since Microsoft removed its built-in SMTP server in Windows Server 2025 and hMailServer is no longer maintained, there are not many simple and free mail forwarding alternatives left on the Windows platform.
Unfortunately the virtual service account is a member of the Users group, which allows it to create files with few restrictions. That makes it pretty useless for a zero-trust install, as far as I can see (IANAWA). For that I think you would have to set up a (non-virtual) account with a password and take a hit on password management.
True, a non-virtual account would allow further restrictions. Still, the virtual service account is already much more secure than LocalSystem, so I'm happy with the solution. It hits the sweet spot balancing security and convenience for me.