[fetchmail]Re: [fetchmail-users] fetchmail 6.2.9-rc3 available

[Matthias Andree]

On Tue, 20 Sep 2005, Thomas Wolff wrote:

> Isn't it the purpose of such tools to enable the users to set up a 
> working mail environment?

It's not the user's task to set up mail environments - and if they have
administrator privileges, they can easily fix their /etc/services.

I cannot afford to support each and every obsolete system for free -
unless "SunOS" implies 5.7 or newer, I'm not terribly interested in it.
If you want support on non-mainstream and pre-SUSv2 systems, you'll
either have to provide patches or pay someone to do them.

> That would also mean they should work "out-of-the-box" in as many 
> situations as possible. It's not the fault of users if they have 
> to work on "broken" systems so don't punish them for it.

There is no "punishment" - it's just that the system is lacking.

> Also I don't see from a software engineering perspective why it should 
> be harmful to consider even "broken" situations and handle them 
> properly in the interest of the user. You may consider it a workaround 

It is "harm"ful, as it increases complexity and reduces the amount of
testing that the code gets. Fetchmail is way too complex already, and it
is particularly full of ugly hacks that are hardcoded - as the recent
AUTH NTLM/MSN for POP3 revealed.

> > ...so does it work to specify the port explicitly on the command line?
> > "--port 993" should work. I don't feel like hacking port numbers in
> > opaque data - that is not the intention of protocol independence
> > patches.

> --port 993 works, thank you. I see that the situation is even well 
> documented under the --port option. It's just not documented where 
> you would normally look for it, so please add a hint to the --ssl 
> option, too, to enable affected users to find the solution.

Fine, I will do that.

> Also, please improve error messages so they may give the unlucky 
> users a hint what to do.
> Currently it looks like this:
> 
> fetchmail: fetchmail: getaddrinfo("msx","imaps") error: servname not for ai_socktype

Hum - looks bogus.

What is the exact system type (uname -a ; ./config.guess)?
What is your /etc/services (egrep 'pop|imap' /etc/services)?

Is that typed manually or pasted? If so, the error message appears
faulty.

> IMAP connection to msx.bln1.siemens.de failed: Bad file number
> fetchmail: Query status=2 (SOCKET)
> 
> and that really does not inspire me to look for the --port option.

Indeed not.

> With the suggested improvements it would be acceptable although I 
> still think that hardcoding a well-defined standard port as a 
> (fallback) default would not be harmful but rather a good feature.

In that case, it should be a general solution rather than a particular
workaround for a single failure point.

-- 
Matthias Andree