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
_______________________________________________
Fetchmail-friends mailing list
Fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
http://lists.ccil.org/cgi-bin/mailman/listinfo/fetchmail-friends