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

[Thomas W. <to...@to...>]

> > The following error remains on SunOS:
> > gcc -I/home/demsn702/opt/openssl-0.9.8/include -I/usr/kerberos/include 
> > -g -O2 -L/home/demsn702/opt/openssl-0.9.8/lib  -o fetchmail  socket.o 
> > getpass.o pop2.o pop3.o imap.o etrn.o odmr.o fetchmail.o env.o idle.o 
> > options.o daemon.o driver.o transact.o sink.o smtp.o uid.o mxget.o 
> > md5ify.o cram.o kerberos.o gssapi.o opie.o rpa.o interface.o netrc.o 
> > unmime.o conf.o checkalias.o smbdes.o smbencrypt.o smbmd4.o smbutil.o 
> > lock.o rcfile_l.o rcfile_y.o norm_charmap.o getaddrinfo.o getnameinfo.o 
> > libfm.a  stpcpy.o  -lnsl -lsocket  -lintl -lresolv -lssl -lcrypto
> > Undefined                       first referenced
> >  symbol                             in file
> > dlclose                             /home/demsn702/lib/libcrypto.a(dso_dlfcn.o)  (symbol belongs to implicit dependency /usr/lib/libdl.so.1)
> 
> Does adding -ldl to LIBS or LDFLAGS help?
Yes. I also see that this is contained somewhere in the configure script 
but it is not generated into the Makefile on SunOS.


> > Also, as I had noted before, fetchmail --ssl apparently depends on 
> > IMAPS being known to the system as a service - probably by listing it 
> > in /etc/services. If this is not the case, getaddrinfo will fail.
> > Now fetchmail seems to be the only tool that enables command line users 
> > to set up a working mail environment on a system which is not 
> > otherwise administrated for handling mail (together with ssmtp).
> > Thus it should not depend on proper system configuration in any respect - 
> 
> Well, fetchmail isn't supported to work on arbitrarily broken systems
> that are years past their end of life. Let's see if we can get it to
> work without hardcoding this information...
Isn't it the purpose of such tools to enable the users to set up a 
working mail environment?
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.

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 
but it's a workaround to an external problem and as such not a 
software deficiency but rather a benefit.


> > it should work even if getaddrinfo does not "know" IMAPS!
> 
> ...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.
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
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.


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.


Kind regards,
Thomas Wolff