Re: [fetchmail-users] fetchmail and socks5

[Jochen H. <Joc...@Ha...>]

>>>>> "MA" == Matthias Andree writes:

> Jochen Hayek writes:

    MA> But why would fetchmail then need its own command line switch at all?

Because that feature needs to get locked out, until it gets explicitly invited.

And the fact that ready-made fetchmails in distros come with not so obvious linked-in socks support
is not really a contradiction,
to the fact, that people don't want that feature until they say "I want it".


Because a fetchmail switch "--use-socks" defaulting to false
would have helped not costing me and others quite a couple of hours.

And maybe far more hours to others, that were not as sick as me, to go here to tell you, there *is* a weird thing with fetchmail.


Pls don't get upset!
I certainly don't consider *you* responsible for that problem.


Who is responsible then? Hard to tell ...

When people attempt socksification of fetchmail (likewise other applications),
they are faced with the suggestion to do it via CPP macros.
If they are lucky, they don't even need to touch their code.
Apparently as long, as no /etc/socks.conf is created, the application continues working as before,
so nobody considers introducing a "--use-socks" switch.
Only at a far later stage impacts and problems appear and get discussed.
Meanwhile the recentyl introduced has long gotten an established feature,
and changing it would break compatibility ...
A good example for the downsides of the bazaar approach ...
(Sorry for this, but I couldn't resist.)

    MA> I mean - if the SOCKS library reads the environment, 
    MA> we can just document this.
    MA> I'll do that now.

A couple of words in the man page and in the FAQ,
that will get found by search machines,
so that googling for "fetchmail socks"
will immediately reveal the problem.

But I guess this thread here will get picked up the search machines anyway
and will also actually help already.


But still:
when *I* couldn't connect to my ISP's IMAP server any longer
I was ***far*** away from googling for "fetchmail socks",
and it took me pretty long to find out,
that I had gone through my socks server for quite a while
(without being aware of it, as I never told fetchmail to do so)
and that I could not connect to the IMAP server, only because my socks server was down.

Now that I know that, it's obviously easy to make use of that env. var. "SOCKS_CONF".
This already found its place in my ~/.profile -- maybe this should even go to /etc/profile :

    export SOCKS_CONF=/dev/null

And wherever I do want to go through the socks server,
I will "prepend" this to a command line:

    env SOCKS_CONF=/etc/socks.conf

e.g.

    env SOCKS_CONF=/etc/socks.conf socksify ftp ...
    env SOCKS_CONF=/etc/socks.conf socksify wget ...
    env SOCKS_CONF=/etc/socks.conf socksify curl ...

Nothing easier than that.

I hated it anyway, that "socksify" does not take command line switches,
and so you are not able to try different socks.conf on the the socksified command lines -- of course *after* the word socksify.
But as we do know by now: you can get this effect through that env. var. -- see above!

    MA> I'm not going to change the default behaviour in 6.3.X releases anyways:
    MA> incompatibilities do not belong in patchlevel update releases. 
    MA> So no putenvs without options.

    MA> Adding even more code to handle yet another option 
    MA> however doesn't seem justified in this case
    MA> -- this new option would just be one different
    MA> formulation for exactly the same purpose
    MA> - and we already have env(1) and shells to handle this.

You are very right.
I cannot blame you for this position.

    MA> It's not the putenv, 
    MA> but the dozens of code lines in the fetchmail dump, option
    MA> parser, rcfile parser, fetchmailconf
    MA> and everywhere else I've forgotten.

    MA> I hope that's acceptable.

It is.

    MA> If it's not, please find some good excuses for me for duplicating the
    MA> environment modification code that is already in env(1)

    MA> - and please one that keeps compatibility with 6.3.7. :-)

My idea was to *break* compatibility here,
as this feature has always been a very bad feature.

Cheers,
Jochen