[GH-ISSUE #1661] fetchmail.profile fails when local delivery to port 25 is needed (netfilter doesn't work)

gitea-mirror commented

2026-05-05 07:29:48 -06:00

Owner

Originally created by @ghost on GitHub (Nov 28, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1661

The command firejail --net=vnet0 --profile=/etc/firejail/fetchmail.profile fetchmail -v myemailacct results in a fetchmail error:

fetchmail: connection to localhost:smtp [::1/25] failed: Connection refused.

Some fetchmail configs need to talk to a local SMTP server; others don't, which was perhaps the assumption in the design of fetchmail.profile. I've tried to fix it by introducing fetchmail.local:

netfilter /etc/firejail/fetchmail.net
whitelist ${HOME}/.netrc

and fetchmail.net:

-A INPUT  -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp --sport 25 -m state --state NEW,ESTABLISHED -j ACCEPT

Same error results. Note that there are no current profiles that pass a file argument to the netfilter option, so in case it's a misuse in my fetchmail.local, I have also tried including --netfilter=/etc/firejail/fetchmail.net on the CLI, and still fails to connect.

Also note that I'm still asked for a password despite whitelisting ${HOME}/.netrc (which is blacklisted in /etc/firejail/disable-common.inc). This seems to suggest that the include /etc/firejail/fetchmail.local may be losing precedence by appearing at the top of the fetchmail.profile.

I also confirm that I have a default firejail.conf (thus restricted-network is no). It's worth pointing out that vnet0 is a tor middlebox in this case (this project). But also note that the tor middlebox is designed to allow local traffic.

/cc @chiraag-nataraj @SpotComms

Originally created by @ghost on GitHub (Nov 28, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1661 The command `firejail --net=vnet0 --profile=/etc/firejail/fetchmail.profile fetchmail -v myemailacct` results in a fetchmail error: ``` fetchmail: connection to localhost:smtp [::1/25] failed: Connection refused. ``` Some fetchmail configs need to talk to a local SMTP server; others don't, which was perhaps the assumption in the design of `fetchmail.profile`. I've tried to fix it by introducing `fetchmail.local`: ``` netfilter /etc/firejail/fetchmail.net whitelist ${HOME}/.netrc ``` and `fetchmail.net`: ``` -A INPUT -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp --sport 25 -m state --state NEW,ESTABLISHED -j ACCEPT ``` Same error results. Note that there are no current profiles that pass a file argument to the `netfilter` option, so in case it's a misuse in my `fetchmail.local`, I have also tried including `--netfilter=/etc/firejail/fetchmail.net` on the CLI, and still fails to connect. Also note that I'm still asked for a password despite whitelisting `${HOME}/.netrc` (which is blacklisted in `/etc/firejail/disable-common.inc`). This seems to suggest that the `include /etc/firejail/fetchmail.local` may be losing precedence by appearing at the top of the `fetchmail.profile`. I also confirm that I have a default `firejail.conf` (thus _restricted-network_ is _no_). It's worth pointing out that `vnet0` is a tor middlebox in this case ([this project](https://github.com/Bylon/TOR_Middlebox)). But also note that the tor middlebox is designed to allow local traffic. /cc @chiraag-nataraj @SpotComms

gitea-mirror

2026-05-05 07:29:48 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 07:29:51 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 2, 2017):

I think you are fighting the network namespace. When you do --net=vnet0, you move fetchmail in a new network namespace with a new loopback interface, and the server on local loopback remains in the regular system namespace. You cannot access the server from the new namespace.

Try without --net=veth0.

@netblue30 commented on GitHub (Dec 2, 2017): I think you are fighting the network namespace. When you do --net=vnet0, you move fetchmail in a new network namespace with a new loopback interface, and the server on local loopback remains in the regular system namespace. You cannot access the server from the new namespace. Try without --net=veth0.

gitea-mirror commented

2026-05-05 07:29:53 -06:00

Author

Owner

@ghost commented on GitHub (Dec 3, 2017):

@netblue30
Thanks, but that makes no difference. I already tested --net=enp0s25 (which is the default network device, and thus presumably the same as omitting the --net option), and still the netfilter seems to fail to allow local port 25 connections.

Also, my ignored whitelisting of /.netrc could be a clue, because if that's being ignored what else is? Maybe my netfilter is also being ignored.

@ghost commented on GitHub (Dec 3, 2017): @netblue30 Thanks, but that makes no difference. I already tested `--net=enp0s25` (which is the default network device, and thus presumably the same as omitting the `--net` option), and still the netfilter seems to fail to allow local port 25 connections. Also, my ignored whitelisting of `/.netrc` could be a clue, because if that's being ignored what else is? Maybe my netfilter is also being ignored.

gitea-mirror commented

2026-05-05 07:29:54 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Dec 4, 2017):

No, using the --net option always creates a new network namespace regardless of which interface you specify. Try it without using --net at all.

@chiraag-nataraj commented on GitHub (Dec 4, 2017): No, using the `--net` option always creates a new network namespace regardless of which interface you specify. Try it without using `--net` at all.

gitea-mirror commented

2026-05-05 07:29:56 -06:00

Author

Owner

@ghost commented on GitHub (Dec 6, 2017):

@chiraag-nataraj

Try it without using --net at all.

That works. Omitting a net namespace enables traffic from fetchmail to the local SMTP server over port 25. So it confirms what @netblue30 said, but problems remain:

There is still a need for traffic from a net namespace-confined fetchmail to the local SMTP server. This is because the namespace is needed to force all remote traffic over Tor. Also note that the trick of adding plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050" to .fetchmailrc does not work because .onion servers do not resolve. Hence the need for a net namespace (which for me is the driver for introducing firejail). How can we poke a hole in the firejail to bridge the LAN with the network namespace, ideally just for port 25?
The ~/.netrc file is still ultimately blocked by global options, despite whitelisting it in /etc/firejail/fetchmail.local. The only workaround specifically for fetchmail is to embed the passphrases in ~/.fetchmailrc instead, because that can be whitelisted (due to lack of global blacklisting). But that's a hack and only works specifically for fetchmail, not other apps that would have a legit reason to access ~/.netrc.

If it's deliberate for global options to block whitelists in localized profiles, then perhaps ~/.fetchmailrc should also be globally blacklisted (as it can contain passwords).

BTW, if the netfilter option is useless in combination with the --net= option, then isn't it a defect that firejail even attempts to execute? Shouldn't it terminate with an error?

@ghost commented on GitHub (Dec 6, 2017): @chiraag-nataraj > Try it without using --net at all. That works. Omitting a net namespace enables traffic from fetchmail to the local SMTP server over port 25. So it confirms what @netblue30 said, but problems remain: * There is still a need for traffic from a net namespace-confined fetchmail to the local SMTP server. This is because the namespace is needed to force all remote traffic over Tor. Also note that the trick of adding `plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050"` to `.fetchmailrc` does not work because `.onion` servers do not resolve. Hence the need for a net namespace (which for me is the driver for introducing firejail). How can we poke a hole in the firejail to bridge the LAN with the network namespace, ideally just for port 25? * The `~/.netrc` file is still ultimately blocked by global options, despite whitelisting it in `/etc/firejail/fetchmail.local`. The only workaround specifically for fetchmail is to embed the passphrases in `~/.fetchmailrc` instead, because that can be whitelisted (due to lack of global blacklisting). But that's a hack and only works specifically for fetchmail, not other apps that would have a legit reason to access `~/.netrc`. If it's deliberate for global options to block whitelists in localized profiles, then perhaps `~/.fetchmailrc` should also be globally blacklisted (as it can contain passwords). BTW, if the _netfilter_ option is useless in combination with the _--net=_ option, then isn't it a defect that firejail even attempts to execute? Shouldn't it terminate with an error?

gitea-mirror commented

2026-05-05 07:29:58 -06:00

Author

Owner

@smitsohu commented on GitHub (Dec 9, 2017):

regarding your second point:

The ~/.netrc file is still ultimately blocked by global options, despite whitelisting it in /etc/firejail/fetchmail.local.

add noblacklist ${HOME}/.netrc to fetchmail.local and try it again

@smitsohu commented on GitHub (Dec 9, 2017): regarding your second point: > The ~/.netrc file is still ultimately blocked by global options, despite whitelisting it in /etc/firejail/fetchmail.local. add `noblacklist ${HOME}/.netrc` to fetchmail.local and try it again

gitea-mirror commented

2026-05-05 07:30:00 -06:00

Author

Owner

@ghost commented on GitHub (Dec 9, 2017):

@smitsohu

add noblacklist ${HOME}/.netrc to fetchmail.local and try it again

Thanks, that worked.

@ghost commented on GitHub (Dec 9, 2017): @smitsohu > add noblacklist ${HOME}/.netrc to fetchmail.local and try it again Thanks, that worked.

gitea-mirror commented

2026-05-05 07:30:02 -06:00

Author

Owner

@smitsohu commented on GitHub (Dec 11, 2017):

perhaps ~/.fetchmailrc should also be globally blacklisted (as it can contain passwords).

@libBletchley Thanks for pointing this out, it is now fixed on mainline

@smitsohu commented on GitHub (Dec 11, 2017): > perhaps ~/.fetchmailrc should also be globally blacklisted (as it can contain passwords). @libBletchley Thanks for pointing this out, it is now fixed on mainline

Rows
Columns

[GH-ISSUE #1661] fetchmail.profile fails when local delivery to port 25 is needed (netfilter doesn't work) #1122