Re: [fetchmail-users] fetchmail and socks5

[Matthias A. <mat...@gm...>]

Jochen Hayek schrieb:
>>>>>> "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".

Well, this feature has been automatically enabled in fetchmail since at
least 6.2.5, and I think we should keep breaking compatibility in this
respect until the next minor or major release -- I'll certainly consider
changing the default for fetchmail 6.4 or 7.0 or whatever version, and
I'm very much inclined to choose defaults that do not surprise the user.

I wonder if there is really a common expectation. Other users might
expect that *if* they have a socks.conf, *then* socks-enabled
applications should use it.

This isn't clear to me, and it's a bet the maintainer will always lose -
one group will be happy and quiet, and the other group will shout. :-)

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

Sorry for that - it's documented now
<http://www.fetchmail.info/fetchmail-FAQ.html#K1> and will also be
documented in the manpage of fetchmail 6.3.8. Feel free to suggest
further changes, the FAQ is surely not cast in concrete.

> A good example for the downsides of the bazaar approach ...
> (Sorry for this, but I couldn't resist.)

Not my essay, and I'm not enthusiastic about several of the assumptions
fetchmail makes, and I'm still pondering whether a complete redesign is
more of an effort than rewriting existing code...

I sympathize with you on the bazaar "appreciation", too.
The "many eyeballs" argument that is invoked so often doesn't hold water
IMO - those eyeballs are only looking after someone has encountered a
*local* problem (or in the rare case some distributor pays for the audit
or some company tries their automated code validator and shares the
results).

The accumulation of dozens of patches, with uncorrected programming
styles, which are really just patches that have often not properly been
integrated - this is a constant headache, and the security fixes that
went into 6.3.6 had to be large as a result of these inconsistencies and
ad-hoc hacking -- and the fallout caused regression fixes in 6.3.7 and
6.3.8. This is the thing I feared most, I did several 6.3.6 release
candidates, but still only field deployment revealed these issues. :-(

Getting distracted a bit, I'd also say beta and rc versions don't work
without contracted beta testers, since users will just wait for the
final release out of convenience - and that's understandable, consumers
don't want unripe garbage...

> 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.

Search engines aren't under my control -- let me know if you want
anything else or suggest changes to the FAQ URL I've given above.

> 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.

If fetchmail were actively enabling socks, then we might just log
additional information to the connecting... ("via socks server XYZ port
N") but this isn't the case. I haven't looked too deep into SOCKS yet
and I'm short on time. I plan to do 6.3.8-rc2 this week and 6.3.8 this
month, so that I can move on to actually opening the 6.4 branch.

-- 
Matthias Andree