Re: need for open-minded help with popularity-contest with systemd timer

On Sun, 26 Jul 2026 at 09:52:37 +0100, Richard Lewis wrote:
>Simon Richter <[email protected]> writes:
>> Can we create a systemd service that sends a mail, and has its own
>> lifetime and permissions?
>
>I think all you need is:
>
>1. a command that takes mail as input, and then passes it to the server
>(this command is run in the caller's cgroup - it will block only until
>the "passes off" part is done, and maybe some basic syntax checking -
>then it can exit)
>
>2. a server that waits for input, and then calls mail(1) to deliver
>it. (I think as long as the server is in a separate systemd .service
>this will all work, as whatever processes the local mta start wont be
>killed if the .service is persistent.)

Thinking outside this particular box in the spirit of open-mindedness, 
is there a reason why popcon needs to submit data via email? Hasn't it 
defaulted to HTTP POST for the last 20+ years, precisely because 
increasingly many systems don't have a fully-configured local MTA, only 
an email client like Thunderbird that is designed to talk directly to 
remote servers, or webmail?

I understand that in principle, e-mail allows popcon to send a message 
at a time convenient to popcon, potentially when the system has no 
network connectivity, and have the message delivered later; but I have 
to wonder how many popcon installations exist where that is practically 
useful.

Similarly, I know that there are probably systems that can reach the 
outside world via an email relay but cannot do "live" HTTP, perhaps 
because of network security restrictions imposed on a locked-down 
network. But how many such systems would enable popcon submissions? If 
your sysadmin team's network control is tight enough to require all HTTP 
to go through proxies or be prevented entirely, then the same sysadmins 
probably don't want end systems to "phone home" to Debian either?

Perhaps it's time to make existing installations switch to submitting 
popcon data via HTTP, with the email transport only used on systems 
where an explicit opt-in has been done?

     smcv