[due to an encoding glitch, this was lost from the ticket.]
Hi Anton:

In message <1716947202.87.0.721227994857.issue2551309@roundup.psfhosted.org>,
Anton Savchuk writes:
>Hello John, sorry for the long silence.

No problem. Async communication is the norm 8-).

>[...] I can't seem to imagine anything better than using a second
>container that has the same mounted volume as the main roundup
>container, but runs a permanent process that has access to the
>trackers and only serves the mail gateway.

They are called sidecar containers in kubernetes and yes I think
that's the way to go.

Also I am assuming you are running one container that serves multiple
trackers. So you also want one container to get email for all of the
trackers.

>This must be something other than a cron running roundup-mailgw,
>since a cron job can only use one mailbox and one tracker.

Umm, not really. You can have multiple cron jobs scheduled running
under one cron binary. E.G.

   0,10,20,30,40,50 * * * * /usr/bin/roundup-mailgw /opt/roundup/trackers/support imap `cat 
/run/secrets/support.imap`  # using docker secrets
   0,10,20,30,40,50 * * * * /usr/bin/roundup-mailgw /opt/roundup/trackers/devel imap `cat 
devel.imap`
   0,10,20,30,40,50 * * * * /usr/bin/roundup-mailgw /opt/roundup/trackers/saleseng imap `cat 
saleseng.imap`

You could hard code the crontab into the image or use a startup script
that gets that info from somewhere and creates the crontab. If you
used docker secrets you can store the info there.

Granted this exposes the credentials on the command line. I thought
there was an option to get this from a config file, but roundup-mailgw
doesn't support reading options from a file (or stdin like
roundup-admin).

I had hoped to find a simple smtp -> program docker container, but all
the SMTP containers are running a full postfix/sendmail/... plus other
services (imap/anti-spam/...). I had hoped to develop somthing using
Python's smtpd module, but that's deprecated so...

>We need to be able to set polling times and mailboxes for each
>tracker. I think it's best if the process gets them from the tracker
>settings file. This allows us to save mailbox credentials in secret
>files.

Agreed. That would have to be added to the configuration
code. Probably in the [mailgw] section. Something like:
mbox_specification as a secret argument that can be obtained from a
file.

I am a little worried about pushing all of the possible arguments for
mailgw into the config file (e.g. schedule times). But putting the
credentials into config.ini makes sense. Maybe roundup-mailgw needs a
'-f' argument that takes a filename with arguments for mailgw.

>I found a wrapper around mailgw.py that runs as a daemon and polls
>IMAP mailboxes. It reads the arguments from the input, but I think
>it’s not difficult to rewrite it to read settings from configuration
>files.

or:

  cat config_file | imapServer.py

no rewriting needed.

>It is located in the scripts/imapServer.py file of the current
>Roundup repository:

I had forgotten about that script. I'm not sure what state it's in but
it looks like Ralf did some updates in 2022.

>I'm not sure we need some kind of asynchronous process. To begin
>with, we can take this wrapper as a starting point.

I'm not sure what you mean by asynchronous process. Do you mean the
ability to schedule each tracker separately?

>Also I'm not sure that for container environments we need anything
>other than IMAP support. POP3 is outdated. Also, no one seems to be
>mounting mailbox directories into a third party container.

Fair enough.

>But, wait... maybe we can using REST API to read the settings and
>communicate with the mail gateway?

Not sure what you mean here. Would you create a new rest endpoint that
triggers mailgw when called?

Or would you have a new rest endpoint return credentials for
roundup-mailgw? The tracker's config.ini has the credentials for
sending email. However IIRC config.ini doesn't have any
credentials/config for receiving email.

>This looks better than searching for mailgw executable on a mounted
>volume.

The roundup docker image doesn't have roundup installed in a mounted
volume.  The mounted volume is strictly for the tracker homes.

The docker image already supports number of subcommands (admin, shell,
demo ..). Adding one more for email would be possible.  Then you would
run the single docker image in two modes (and two containers). Default
mode (which runs roundup-server) and email mode which runs imapServer.

Have a great day.