[pmg-devel] [PATCH pmg-api v2 0/2] improve fetchmail handling in PMG

[pmg-devel] [PATCH pmg-api v2 0/2] improve fetchmail handling in PMG

[Stoiko Ivanov]

supersedes: https://lore.proxmox.com/pmg-devel/20250924113247.50931-1-s.ivanov@proxmox.com/T/#t

v1->v2:
* rework the commit messages after reading them through.

pmg-api:
Stoiko Ivanov (2):
  fix #6798: fetchmail: adapt to changed sslproto semantics
  templates: fetchmail: add comment where users can add manual accounts

 src/PMG/Fetchmail.pm         | 13 ++++++++++++-
 src/templates/fetchmailrc.tt |  3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

package-rebuilds:
Stoiko Ivanov (1):
  fetchmail: improve shipped service file

 pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.47.3



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

[pmg-devel] [PATCH pmg-api v2 1/2] fix #6798: fetchmail: adapt to changed sslproto semantics

[Stoiko Ivanov]

fetchmail defaults to verifying certificates since version 6.4.0
see fetchmail(1)
- sslproto defaults to auto instead of ''
- when sslproto is not '' then implicit/opportunistic TLS (StartTLS)
  is tried over the plain-text port
- this results in the current config parsing and writing to always
  try a TLS-connection if the server offers starttls

additionally sslcertck (only accept trusted certificates) defaults to
true since 6.4.0

The combination of these two things has as a consequence, that
unsetting 'use SSL' will fail for servers which have a self-signed
certificate installed (I expect many to still do so).

This patch simply fixes the 'use SSL' flag to disable all TLS
(explicit and opportunistic) and thus keep the expectations of users.

I did consider changing this to:
* either add a checkbox to ignore an invalid certificate (which feels
  quite wrong).
* allow users to provide a fingerprint instead (not considered
  further as fetchmail (in trixie) uses MD5 fingerprints, and this
  seems a step back).
* keep things as they currently are and document that users need to
  add the self-signed certificate to the system-trust-store
  (/usr/local/share/ca-certificates)

Since we ship versions with the semantic change since PMG 6.x (buster
shipped 6.4.0~beta43[0]) I don't think many users who use fetchmail
ran into this in the past few years - and most ISPs/mail providers
have valid certificates nowadays. So the potential for regression
should not be too large.

We could consider deprecating plain-text IMAP/POP in a future version,
but I'd announce the deprecation with 9.0 to give it some visibility.

[0] https://manpages.debian.org/buster/fetchmail/fetchmail.1.en.html

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
---
 src/PMG/Fetchmail.pm | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/PMG/Fetchmail.pm b/src/PMG/Fetchmail.pm
index 3a647420..c35e03d8 100644
--- a/src/PMG/Fetchmail.pm
+++ b/src/PMG/Fetchmail.pm
@@ -143,6 +143,11 @@ sub read_fetchmail_conf {
 
         my $finalize_item = sub {
             my ($item) = @_;
+
+            if ($item->{ssl} && !$item->{ssl_proto}) {
+                die "conflicting SSL settings for $item->{id}\n" if $item->{enabled};
+            }
+
             $cfg->{ $item->{id} } = $item;
         };
 
@@ -174,6 +179,8 @@ sub read_fetchmail_conf {
                 $item->{port} = $get_token_argument->();
             } elsif ($token eq 'interval') {
                 $item->{interval} = $get_token_argument->();
+            } elsif ($token eq 'sslproto') {
+                $item->{sslproto} = $get_token_argument->();
             } elsif (
                 $token eq 'ssl'
                 || $token eq 'keep'
@@ -210,7 +217,11 @@ sub write_fetchmail_conf {
         }
         $set_fetchmail_defaults->($item);
         my $options = ['dropdelivered'];
-        push @$options, 'ssl' if $item->{ssl};
+        if ($item->{ssl}) {
+            push @$options, 'ssl';
+        } else {
+            push @$options, ('sslproto', '\'\'');
+        }
         push @$options, 'keep' if $item->{keep};
         $item->{options} = join(' ', @$options);
         $data->{$id} = $item;
-- 
2.47.3



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

[pmg-devel] [PATCH pmg-api v2 2/2] templates: fetchmail: add comment where users can add manual accounts

[Stoiko Ivanov]

our fetchmail module uses /etc/fetchmailrc (symlinked to
/etc/pmg/fetchmailrc) as authoritative source for fetchmail accounts.

This means that if users need to make adaptations to fetchmail options
it breaks the handling of fetchmail in the API and GUI.

based on feedback from #6798 I think providing a hint where users
can add accounts with manual overrides, while keeping the API/GUI
working for all other accounts should help.

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
---
 src/templates/fetchmailrc.tt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/templates/fetchmailrc.tt b/src/templates/fetchmailrc.tt
index 76e591ca..f7f341de 100644
--- a/src/templates/fetchmailrc.tt
+++ b/src/templates/fetchmailrc.tt
@@ -9,6 +9,9 @@ defaults:
 
 smtphost [% ipconfig.int_ip %]/[% pmg.mail.ext_port %]
 
+# add manually configured accounts below and before 'proxmox settings'(to keep the UI working)
+
+
 # proxmox settings (Do not delete this marker!!)
 [% FOREACH item IN fetchmail_users.list('values') %]
 [% IF item.enable %]poll[% ELSE %]skip[% END -%]
-- 
2.47.3



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

Re: [pmg-devel] [PATCH pmg-api v2 2/2] templates: fetchmail: add comment where users can add manual accounts

[Max R. Carrara]

On Wed Sep 24, 2025 at 8:05 PM CEST, Stoiko Ivanov wrote:
> our fetchmail module uses /etc/fetchmailrc (symlinked to
> /etc/pmg/fetchmailrc) as authoritative source for fetchmail accounts.
>
> This means that if users need to make adaptations to fetchmail options
> it breaks the handling of fetchmail in the API and GUI.
>
> based on feedback from #6798 I think providing a hint where users
> can add accounts with manual overrides, while keeping the API/GUI
> working for all other accounts should help.
>
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
>  src/templates/fetchmailrc.tt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/templates/fetchmailrc.tt b/src/templates/fetchmailrc.tt
> index 76e591ca..f7f341de 100644
> --- a/src/templates/fetchmailrc.tt
> +++ b/src/templates/fetchmailrc.tt
> @@ -9,6 +9,9 @@ defaults:
>  
>  smtphost [% ipconfig.int_ip %]/[% pmg.mail.ext_port %]
>  
> +# add manually configured accounts below and before 'proxmox settings'(to keep the UI working)

Small nit: would add a space after 'proxmox settings' above, so the
parenthesis isn't glued to it:

  add manually configured accounts below and before 'proxmox settings' (to keep the UI working)

Alternatively, the text in parentheses can also go to be fair; users
don't necessarily need to know up front that the UI will break if they
edit the wrong parts of the file, IMO.

> +
> +
>  # proxmox settings (Do not delete this marker!!)
>  [% FOREACH item IN fetchmail_users.list('values') %]
>  [% IF item.enable %]poll[% ELSE %]skip[% END -%]



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

[pmg-devel] [PATCH package-rebuilds v2 1/1] fetchmail: improve shipped service file

[Stoiko Ivanov]

fetchmail exits with exit-code 3 if:
'The user authentication step failed...' (see fetchmail(1)).
This also includes the case if there are no accounts configured for
fetching, e.g. if all accounts are configured with 'skip' instead of
'poll'. In PMG you get this when temporary disaling all configured
accounts in the GUI.

So we simply should not consider an exit of 3 as failure.
Additionally adapt the Restart value to 'on-failure' (else systemd
tries restarting 5 times and gives up)
see systemd.service(5).

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
---
 pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
index a6e3168..b7260ac 100644
--- a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
+++ b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
@@ -21,7 +21,8 @@ User=fetchmail
 Type=exec
 # sort $OPTIONS after "-daemon 300" to allow overwriting the interval using $OPTIONS
 ExecStart=/usr/bin/fetchmail --daemon 300 $OPTIONS --nodetach -f /etc/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid
-Restart=always
+SuccessExitStatus=3
+Restart=on-failure
 
 [Install]
 WantedBy=multi-user.target
-- 
2.47.3



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

Re: [pmg-devel] [PATCH package-rebuilds v2 1/1] fetchmail: improve shipped service file

[Max R. Carrara]

On Wed Sep 24, 2025 at 8:05 PM CEST, Stoiko Ivanov wrote:
> fetchmail exits with exit-code 3 if:
> 'The user authentication step failed...' (see fetchmail(1)).
> This also includes the case if there are no accounts configured for
> fetching, e.g. if all accounts are configured with 'skip' instead of
> 'poll'. In PMG you get this when temporary disaling all configured
> accounts in the GUI.

s/disaling/disabling ;)

>
> So we simply should not consider an exit of 3 as failure.
> Additionally adapt the Restart value to 'on-failure' (else systemd
> tries restarting 5 times and gives up)
> see systemd.service(5).

But wouldn't this mean that if I e.g. temporarily disable all configured
accounts, `fetchmail.service` would exit with `3` and then never restart
again? Or am I mistaken here?

That being said, `fetchmail.service` refuses to start for me on my most
recent test VMs, even though I have added a dummy entry in the UI.
I might be holding it wrong, but `/etc/default/fetchmail` is never being
written to; it's empty for me.

# systemctl status fetchmail.service
○ fetchmail.service - fetchmail mail retriever agent
     Loaded: loaded (/usr/lib/systemd/system/fetchmail.service; enabled; preset: enabled)
     Active: inactive (dead) (Result: exec-condition) since Thu 2025-09-25 18:47:38 CEST; 6min ago
 Invocation: e87235808c58412883ec5c2ad55ab248
  Condition: start condition unmet at Thu 2025-09-25 18:47:38 CEST; 6min ago
       Docs: man:fetchmail(1)
    Process: 2239 ExecCondition=/bin/sh -c [ "$START_DAEMON" = "yes" ] (code=exited, status=1/FAILURE)
   Mem peak: 1.7M
        CPU: 5ms

Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: Starting fetchmail.service - fetchmail mail retriever agent...
Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: fetchmail.service: Skipped due to 'exec-condition'.
Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: Condition check resulted in fetchmail.service - fetchmail mail retriever agent being skipped.


All of that aside, I think it would make more sense to keep
`Restart=always` but add `SuccessExitStatus=3`, as well as
`RestartSec=` to control how quickly the service is restarted [0].

Since the daemonized fetchmail sleeps for 300 seconds before running
again, we could maybe set `RestartSec=300`, so that systemd waits for
five minutes before trying to start `fetchmail.service` again. That way
the daemon isn't restarted immediately when it fails; or in other words,
mails are fetched every 5 minutes, even on failure.

Additionally, it might be favorable to explicitly set
`StartLimitIntervalSec=` and `StartLimitBurst=` [1] here, because the
default retry count is 5 (as you already noticed), in case setting
`RestartSec` alone is insufficient for some reason.

FWIW, you can find the defaults for the above two values using
`cat /etc/systemd/system.conf | grep StartLimit`

[0]: `man 5 systemd.service`
[1]: `man 5 systemd.unit`

>
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
>  pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> index a6e3168..b7260ac 100644
> --- a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> +++ b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> @@ -21,7 +21,8 @@ User=fetchmail
>  Type=exec
>  # sort $OPTIONS after "-daemon 300" to allow overwriting the interval using $OPTIONS
>  ExecStart=/usr/bin/fetchmail --daemon 300 $OPTIONS --nodetach -f /etc/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid
> -Restart=always
> +SuccessExitStatus=3
> +Restart=on-failure
>  
>  [Install]
>  WantedBy=multi-user.target



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

Re: [pmg-devel] [PATCH package-rebuilds v2 1/1] fetchmail: improve shipped service file

[Max R. Carrara]

On Thu Sep 25, 2025 at 7:07 PM CEST, Max R. Carrara wrote:
> On Wed Sep 24, 2025 at 8:05 PM CEST, Stoiko Ivanov wrote:
> > fetchmail exits with exit-code 3 if:
> > 'The user authentication step failed...' (see fetchmail(1)).
> > This also includes the case if there are no accounts configured for
> > fetching, e.g. if all accounts are configured with 'skip' instead of
> > 'poll'. In PMG you get this when temporary disaling all configured
> > accounts in the GUI.
>
> s/disaling/disabling ;)
>
> >
> > So we simply should not consider an exit of 3 as failure.
> > Additionally adapt the Restart value to 'on-failure' (else systemd
> > tries restarting 5 times and gives up)
> > see systemd.service(5).
>
> But wouldn't this mean that if I e.g. temporarily disable all configured
> accounts, `fetchmail.service` would exit with `3` and then never restart
> again? Or am I mistaken here?
>
> That being said, `fetchmail.service` refuses to start for me on my most
> recent test VMs, even though I have added a dummy entry in the UI.
> I might be holding it wrong, but `/etc/default/fetchmail` is never being
> written to; it's empty for me.
>
> # systemctl status fetchmail.service
> ○ fetchmail.service - fetchmail mail retriever agent
>      Loaded: loaded (/usr/lib/systemd/system/fetchmail.service; enabled; preset: enabled)
>      Active: inactive (dead) (Result: exec-condition) since Thu 2025-09-25 18:47:38 CEST; 6min ago
>  Invocation: e87235808c58412883ec5c2ad55ab248
>   Condition: start condition unmet at Thu 2025-09-25 18:47:38 CEST; 6min ago
>        Docs: man:fetchmail(1)
>     Process: 2239 ExecCondition=/bin/sh -c [ "$START_DAEMON" = "yes" ] (code=exited, status=1/FAILURE)
>    Mem peak: 1.7M
>         CPU: 5ms
>
> Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: Starting fetchmail.service - fetchmail mail retriever agent...
> Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: fetchmail.service: Skipped due to 'exec-condition'.
> Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: Condition check resulted in fetchmail.service - fetchmail mail retriever agent being skipped.

Quick follow-up regarding fetchmail.service: As we just spotted
off-list, `/etc/default/fetchmail` isn't set up during installation,
and also doesn't appear after `apt-get install --reinstall fetchmail`.

>
>
> All of that aside, I think it would make more sense to keep
> `Restart=always` but add `SuccessExitStatus=3`, as well as
> `RestartSec=` to control how quickly the service is restarted [0].
>
> Since the daemonized fetchmail sleeps for 300 seconds before running
> again, we could maybe set `RestartSec=300`, so that systemd waits for
> five minutes before trying to start `fetchmail.service` again. That way
> the daemon isn't restarted immediately when it fails; or in other words,
> mails are fetched every 5 minutes, even on failure.
>
> Additionally, it might be favorable to explicitly set
> `StartLimitIntervalSec=` and `StartLimitBurst=` [1] here, because the
> default retry count is 5 (as you already noticed), in case setting
> `RestartSec` alone is insufficient for some reason.
>
> FWIW, you can find the defaults for the above two values using
> `cat /etc/systemd/system.conf | grep StartLimit`
>
> [0]: `man 5 systemd.service`
> [1]: `man 5 systemd.unit`

Also as discussed off-list, the above changes aren't necessary and yours
down below are fine; I hadn't considered that we manually restart
`fetchmail.service` if the user updates the config. Might be nice to
note that in the commit message for future reference though. (That is,
that we let the service exit gracefully here and that it's restarted
automatically when the user adds or re-enables the fetchmail accounts
via the UI).

>
> >
> > Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> > ---
> >  pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> > index a6e3168..b7260ac 100644
> > --- a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> > +++ b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> > @@ -21,7 +21,8 @@ User=fetchmail
> >  Type=exec
> >  # sort $OPTIONS after "-daemon 300" to allow overwriting the interval using $OPTIONS
> >  ExecStart=/usr/bin/fetchmail --daemon 300 $OPTIONS --nodetach -f /etc/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid
> > -Restart=always
> > +SuccessExitStatus=3
> > +Restart=on-failure
> >  
> >  [Install]
> >  WantedBy=multi-user.target



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

Re: [pmg-devel] [PATCH package-rebuilds v2 1/1] fetchmail: improve shipped service file

[Max R. Carrara]

On Wed Sep 24, 2025 at 8:05 PM CEST, Stoiko Ivanov wrote:
> fetchmail exits with exit-code 3 if:
> 'The user authentication step failed...' (see fetchmail(1)).
> This also includes the case if there are no accounts configured for
> fetching, e.g. if all accounts are configured with 'skip' instead of
> 'poll'. In PMG you get this when temporary disaling all configured
> accounts in the GUI.
>
> So we simply should not consider an exit of 3 as failure.
> Additionally adapt the Restart value to 'on-failure' (else systemd
> tries restarting 5 times and gives up)
> see systemd.service(5).

Would mention here that the user still has to run
`systemctl restart fetchmail.service` if all fetchmail accounts were
disabled and they re-enabled at least one of them again, as we don't do
this automatically and only restart `fetchmail.service` when the first
account is added. (Also correcting my earlier response [0] here.)

>
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
>  pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> index a6e3168..b7260ac 100644
> --- a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> +++ b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> @@ -21,7 +21,8 @@ User=fetchmail
>  Type=exec
>  # sort $OPTIONS after "-daemon 300" to allow overwriting the interval using $OPTIONS
>  ExecStart=/usr/bin/fetchmail --daemon 300 $OPTIONS --nodetach -f /etc/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid
> -Restart=always
> +SuccessExitStatus=3
> +Restart=on-failure
>  
>  [Install]
>  WantedBy=multi-user.target

---

On a side note: Perhaps we could improve the handling for
`fetchmail.service` in the future a little? For example ...

- User adds first account, keeping it *disabled*
  - Current behavior:
    We set `START_DAEMON=yes` in `/etc/default/fetchmail` and restart 
    `fetchmail.service` [1], because disabled accounts are also
    counted [2]. This has the consequence that `fetchmail.service`
    immediately exits, which the user might not notice.

  - Suggestion:
    Only do the above if the user adds an *enabled* account.

- User deactivates all accounts, then re-enables at least one of them a
  little later
  - Current behavior:
    `fetchmail.service` will exit, because all accounts are disabled.
    When the user re-enables an account, `fetchmail.service` remains
    stopped; thus the user has to manually restart the service.

  - Suggestion:
    Note in the docs that this is something the user has to do; explain
    that they can do it via Administration > Services > fetchmail >
    Click on "Start" button or via the CLI.

    Any other automatic means of starting `fetchmail.service` would
    change the current bevhaior which might not be what (experienced)
    PMG admins desire.

I don't think that these things are super-duper necessary or something;
but thought I'd share my thoughts. Let me know what you think!

[0]: https://lore.proxmox.com/pmg-devel/DD2MMUB49BFN.ZOWZTQYB9TP0@proxmox.com/
[1]: https://git.proxmox.com/?p=pmg-api.git;a=blob;f=src/PMG/Fetchmail.pm;h=3a64742059f625fe3e0306ea3c59034cedef9536;hb=refs/heads/master#l238
[2]: https://git.proxmox.com/?p=pmg-api.git;a=blob;f=src/PMG/Fetchmail.pm;h=3a64742059f625fe3e0306ea3c59034cedef9536;hb=refs/heads/master#l205



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

Re: [pmg-devel] [PATCH pmg-api v2 0/2] improve fetchmail handling in PMG

[Max R. Carrara]

On Wed Sep 24, 2025 at 8:05 PM CEST, Stoiko Ivanov wrote:
> supersedes: https://lore.proxmox.com/pmg-devel/20250924113247.50931-1-s.ivanov@proxmox.com/T/#t
>
> v1->v2:
> * rework the commit messages after reading them through.
>
> pmg-api:
> Stoiko Ivanov (2):
>   fix #6798: fetchmail: adapt to changed sslproto semantics
>   templates: fetchmail: add comment where users can add manual accounts
>
>  src/PMG/Fetchmail.pm         | 13 ++++++++++++-
>  src/templates/fetchmailrc.tt |  3 +++
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> package-rebuilds:
> Stoiko Ivanov (1):
>   fetchmail: improve shipped service file
>
>  pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Gave this series a spin on my most recent two-node cluster I set up for
testing.

Note: Instead of applying and building our rebuild of `fetchmail`, I
used systemd overrides (via `systemctl edit fetchmail.service`) to set
the options in patch #3; has the same effect, but saved me some time.

- Smoke-tested patch #1 by setting up fetchmail for our mailserver via
  IMAP, using SSL, my own credentials as well as a dummy recipient

- Mails were fetched successfully according to the logs
  --> Mail server using a cert that isn't self-signed works (patch #1)

- `fetchmail.service` exited gracefully after disabling the user's
  entry (patch #3)

○ fetchmail.service - fetchmail mail retriever agent
     Loaded: loaded (/usr/lib/systemd/system/fetchmail.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/fetchmail.service.d
             └─override.conf
     Active: inactive (dead) since Fri 2025-09-26 13:01:10 CEST; 4min 25s ago
   Duration: 5min 211ms
 Invocation: ca50a0619b934676b631588b4d337980
       Docs: man:fetchmail(1)
    Process: 6690 ExecCondition=/bin/sh -c [ "$START_DAEMON" = "yes" ] (code=exited, status=0/SUCCESS)
    Process: 6693 ExecStart=/usr/bin/fetchmail --daemon 300 $OPTIONS --nodetach -f /etc/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid (code=exited, status=3)
   Main PID: 6693 (code=exited, status=3)
   Mem peak: 3.1M
        CPU: 24ms

Sep 26 12:56:10 pmg-9-beta-01 systemd[1]: Starting fetchmail.service - fetchmail mail retriever agent...
Sep 26 12:56:10 pmg-9-beta-01 systemd[1]: Started fetchmail.service - fetchmail mail retriever agent.
Sep 26 12:56:10 pmg-9-beta-01 fetchmail[6693]: fetchmail: starting fetchmail 6.4.39 daemon
Sep 26 12:56:10 pmg-9-beta-01 fetchmail[6693]: 824 messages (824 seen) for m.carrara@proxmox.com at proxmox0001.
Sep 26 13:01:10 pmg-9-beta-01 fetchmail[6693]: fetchmail: restarting fetchmail (/etc/fetchmailrc changed)
Sep 26 13:01:10 pmg-9-beta-01 fetchmail[6693]: fetchmail: starting fetchmail 6.4.39 daemon
Sep 26 13:01:10 pmg-9-beta-01 fetchmail[6693]: fetchmail: All connections are wedged.  Exiting.
Sep 26 13:01:10 pmg-9-beta-01 systemd[1]: fetchmail.service: Deactivated successfully.

So, exit code 3 is interpreted as a successful exit status by systemd.
Admins will still have to `systemctl restart fetchmail.service` if they
re-enable all fetchmail users again, but now the service doesn't die
on the spot anymore if no users are enabled. Neat!

So, overall LGTM; see the comments inline in patch #2 and #3 though.
Those can be addressed when applying the series, so I don't think a
v3 is necessary.

Consider:

Tested-by: Max R. Carrara <m.carrara@proxmox.com>
Reviewed-by: Max R. Carrara <m.carrara@proxmox.com>


_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

[pmg-devel] superseded: [PATCH pmg-api v2 0/2] improve fetchmail handling in PMG

[Stoiko Ivanov]

superseded by:
https://lore.proxmox.com/pmg-devel/20250926192941.89086-1-s.ivanov@proxmox.com/T/#t

On Wed, 24 Sep 2025 20:05:12 +0200
Stoiko Ivanov <s.ivanov@proxmox.com> wrote:

> supersedes: https://lore.proxmox.com/pmg-devel/20250924113247.50931-1-s.ivanov@proxmox.com/T/#t
> 
> v1->v2:
> * rework the commit messages after reading them through.
> 
> pmg-api:
> Stoiko Ivanov (2):
>   fix #6798: fetchmail: adapt to changed sslproto semantics
>   templates: fetchmail: add comment where users can add manual accounts
> 
>  src/PMG/Fetchmail.pm         | 13 ++++++++++++-
>  src/templates/fetchmailrc.tt |  3 +++
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> package-rebuilds:
> Stoiko Ivanov (1):
>   fetchmail: improve shipped service file
> 
>  pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel