Public bug reported: Protonmail-Hydroxide users are inconvenienced with having to manually execute this command prior to running fetchmail:
$ torsocks hydroxide imap The fetchmailrc stanza looks like this: skip protonmail-hydroxide via 127.0.0.1 protocol imap port 1143 username "billyikes" sslproto '' fetchall The workflow above functions, but it's a nuissance to have to execute a daemon manually before running fetchmail. In principle, it would be ideal to add: 'plugin "torsocks hydroxide imap"', but the problem is that fetchmail has the limitation of having to interact with plugins through standard I/O, which is unsupported by hydroxide. I suggest adding the following options: stdio <boolean> plugin_is_a_daemon <boolean> kill_plugin <boolean> If the stdio boolean is true, then the plugin mechanism works the way it always has. If the boolean is false, then fetchmail connects to the IP and port given in the stanza. If plugin_is_a_daemon is true, then fetchmail should check whether the process is already running and if not fetchmail should launch it and disown it before fetching the mail. If kill_plugin is true, fetchmail should kill the plugin after each fetch. Perhaps those 3 options could be consolidated into fewer options but I'm merely brainstorming the degree of control that would be useful to users. *Alternatively* Perhaps there is a hack that avoids a fetchmail code change. For example, would it work to layer in socat alongside hydroxide? Such as: plugin "torsocks hydroxide imap & socat STDIO TCP:127.0.0.1:%h:%p" I'm not real proficient with socat (it's very complex), but if there is a way to launch hydroxide and combine socat as middleware to keep fetchmail code simple, then this feature request could boil down to simply adding an example of a hydroxide configuration to the man page. FYI, Hydroxide lives here: https://github.com/emersion/hydroxide BTW, I know the upstream tracker is normally the appropriate place for feature requests, but gitlab.com is inaccessible to myself and probably many others (largely people using Tor or whose ISP uses CGNAT). So I've posted it here just to get it on record, in hopes that an upstream developer sees it. ** Affects: fetchmail (Ubuntu) Importance: Undecided Status: New ** Description changed: Protonmail-Hydroxide users are inconvenienced with having to manually execute this command prior to running fetchmail: $ torsocks hydroxide imap The fetchmailrc stanza looks like this: skip protonmail-hydroxide via 127.0.0.1 - protocol imap - port 1143 - username "billyikes" - sslproto '' - fetchall + protocol imap + port 1143 + username "billyikes" + sslproto '' + fetchall The workflow above functions, but it's a nuissance to have to execute a daemon manually before running fetchmail. In principle, it would be ideal to add: 'plugin "torsocks hydroxide imap"', but the problem is - that fetchmail has the limitation of having to use standard I/O, which - is unsupported by hydroxide. + that fetchmail has the limitation of having to interact with plugins + through standard I/O, which is unsupported by hydroxide. I suggest adding the following options: stdio <boolean> plugin_is_a_daemon <boolean> kill_plugin <boolean> If the stdio boolean is true, then the plugin mechanism works the way it always has. If the boolean is false, then fetchmail connects to the IP and port given in the stanza. If plugin_is_a_daemon is true, then fetchmail should check whether the process is already running and if not fetchmail should launch it and disown it before fetching the mail. If kill_plugin is true, fetchmail should kill the plugin after each fetch. Perhaps those 3 options could be consolidated into fewer options but I'm merely brainstorming the degree of control that would be useful to users. *Alternatively* Perhaps there is a hack that avoids a fetchmail code change. For example, would it work to layer in socat alongside hydroxide? Such as: plugin "torsocks hydroxide imap & socat STDIO TCP:127.0.0.1:%h:%p" I'm not real proficient with socat (it's very complex), but if there is a way to launch hydroxide and combine socat as middleware to keep fetchmail code simple, then this feature request could boil down to simply adding an example of a hydroxide configuration to the man page. FYI, Hydroxide lives here: https://github.com/emersion/hydroxide ** Description changed: Protonmail-Hydroxide users are inconvenienced with having to manually execute this command prior to running fetchmail: $ torsocks hydroxide imap The fetchmailrc stanza looks like this: skip protonmail-hydroxide via 127.0.0.1 protocol imap port 1143 username "billyikes" sslproto '' fetchall The workflow above functions, but it's a nuissance to have to execute a daemon manually before running fetchmail. In principle, it would be ideal to add: 'plugin "torsocks hydroxide imap"', but the problem is that fetchmail has the limitation of having to interact with plugins through standard I/O, which is unsupported by hydroxide. I suggest adding the following options: stdio <boolean> plugin_is_a_daemon <boolean> kill_plugin <boolean> If the stdio boolean is true, then the plugin mechanism works the way it always has. If the boolean is false, then fetchmail connects to the IP and port given in the stanza. If plugin_is_a_daemon is true, then fetchmail should check whether the process is already running and if not fetchmail should launch it and disown it before fetching the mail. If kill_plugin is true, fetchmail should kill the plugin after each fetch. Perhaps those 3 options could be consolidated into fewer options but I'm merely brainstorming the degree of control that would be useful to users. *Alternatively* Perhaps there is a hack that avoids a fetchmail code change. For example, would it work to layer in socat alongside hydroxide? Such as: plugin "torsocks hydroxide imap & socat STDIO TCP:127.0.0.1:%h:%p" I'm not real proficient with socat (it's very complex), but if there is a way to launch hydroxide and combine socat as middleware to keep fetchmail code simple, then this feature request could boil down to simply adding an example of a hydroxide configuration to the man page. FYI, Hydroxide lives here: https://github.com/emersion/hydroxide + + BTW, I know the upstream tracker is normally the appropriate place for + feature requests, but gitlab.com is inaccessible to myself and probably + many others (largely people using Tor or whose ISP uses CGNAT). So I've + posted it here just to get it on record, in hopes that an upstream + developer sees it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938719 Title: (feature request) support for non-stdio plugins (like Hydroxide) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1938719/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
