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