Re: [fetchmail-users] fetchmail and socks5

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

Jochen Hayek schrieb:

>> On 3/18/07, Matthias Andree <mat...@gm...> wrote:
> 
>     MA> That's the distributor's business, 
>     MA> not that of the fetchmail maintainers.
> 
> Well I think, at the end of the day it's "the user's" problem,
> and I guess 99% of the fetchmail users employ a ready-made installation,
> and fetchmail is giving them grief, if it assumes uncomfortable defaults.

Sorry to those who are bored by this discussion, but as this is still
boiling, I must conclude the participants are unhappy with the state of
the discussion. Let's try to break this down to objective criteria and
understand the actual cause of these emotions.

Up front, maintainers are loathe to change system behavior, because that
causes users pain, causes complaints, support work and all else we don't
want. Trying to satisfy contradictory requirements leads either to a
majority vote, a maintainer vote, or a configuration option.

We know the configuration option at run-time isn't feasible beyond
SOCKS_CONF -- which itself invalidates the need for a
command-line/rcfile option in fetchmail.

The questions I'm having:

1. What good is SOCKS, anyways?
   Why use SOCKS if I can have IPFW, IPFW2, PF, netfilter?

2. What was the original problem or surprise?
   You configured socks, which implies assigning socks proxies to
   certain destination addresses/networks.
   Your proxy went down, so you could not connect. So what?
   In SOCKS scenarios, the SOCKS proxy is the interface to the outside
   world, and indispensable in such configurations.
   Not a surprise to me.

   If there is a relevant standard (IETF, LSB, IEEE...) that states how
   socks-enabled applications should behave, I'll reconsider.

3. What is the scenario in production where each application had its own
   socks configuration? In what way is the SOCKS_CONF
   configuration mechanism insufficient?

   Why do you think fetchmail should try to be smarter than the user and
   stomp over his environment variables or configuration files?

4. Would not it be more fruitful if the end user talked to the
   distributor who packaged fetchmail with the *nondefault*
   --with-socks[5] option rather than offering socksify or similar?

   The upstream default - at compile time - already is "no socks".

> Obviously everybody may have his/her own position on what is (un)comfortable in this respect.
> But maybe "relevance of positions" should somehow relate to "competence and experience in *the* area and *not* *just* in IT".

I understand your double frustration, first the socks irritations as
such, and then that the upstream maintainers we don't see reasons to
change existing code soon in spite of your desperate attempts to
convince them.

Note that invoking experience in a certain area isn't a valid reason to
support your suggestions. I'll rather look at objective arguments.

I hope to ground the unhealthy emotions from this discussion and get to
the core arguments.

Best,
Matthias