Rolling Resource

You can setup ip filtering from your site manager. Just click on Site Management / IP Filtering. Enter an IP address of ‘*’ for Other and that will block to all ports EXCEPT 25 (SMTP), 110 (POP3), 80 (HTTP) and 21 (FTP). You would then have to create another rule to allow access from your IP to Other ports.

If you wanted to specifically block port 3306, then you might be able to add the file p3306 to /etc/hd/inf However, there is no guarantee that this would work as the ipf utility is a Westhost VPS special. These files have the format of one line per IP block, beginning with d for Deny or a for Allow. For example:
d 10.0.0.1
a 127.0.0.1

Worked for me. what is the URL of your form?
Can you get your form to send you anything? If so, then you should just need to add

to your form. I have meddled with my FormMail, but the basic functionality is the same. Maybe you've included some reserved characters such as # in your message.

I have downloaded and installed GnuPG, but whenever I try to retrieve a public key from a keyserver, it logs the error
gpgkeys_hkp: error while loading shared libraries: libcurl.so.3: cannot open shared object file: No such file or directory

This is despite the fact that libcurl.so.3 is on my system
$ find / -name libcurl.so* 2>/dev/null
/usr/local/lib/libcurl.so
/usr/local/lib/libcurl.so.3
/usr/local/lib/libcurl.so.3.0.0
/usr/local/phplibs/lib/libcurl.so
/usr/local/phplibs/lib/libcurl.so.3
/usr/local/phplibs/lib/libcurl.so.3.0.0
/usr/home/mylogin/apps/bld/curl-7.16.0/lib/.libs/libcurl.so.4.0.0
/usr/home/mylogin/apps/bld/curl-7.16.0/lib/.libs/libcurl.so.4
/usr/home/mylogin/apps/bld/curl-7.16.0/lib/.libs/libcurl.so
/usr/mylocal/lib/libcurl.so.4.0.0
/usr/mylocal/lib/libcurl.so.4
/usr/mylocal/lib/libcurl.so
/ftp/usr/lib/libcurl.so
/ftp/usr/lib/libcurl.so.1
/ftp/usr/lib/libcurl.so.1.1.0
/ftp/usr/lib/libcurl.so.2

In fact it appears twice, once in /usr/local/lib and again in /usr/local/phplibs/lib.  So what is going on?  It would appear that while my system can locate the file in order to build it into the executable, it cannot locate the library at run time (when I run gpg); no errors were logged when I configured and made GnuPG. There is a useful article (here) by David Wheeler which explains how libraries work. It explains the difference between soname, realname and linker name and how the various links are created as part of the build process. It goes on to explain that when you install a new version of a library, you install it in one of a few special directories and then run the program ldconfig(8) in order to update the file /etc/ld.so.cache. These special directories are defined in /etc/ld.so.conf
When we look at ld.so.conf, it has two lines

[mylogin][~]$ cat /etc/ld.so.conf
/usr/local/lib
/lib

so the system should find the link in /usr/local/lib. (/lib is actually a symbolic link to /ftp/usr/lib) However, when I checked the cache, the file is missing

[mylogin][~]$ ldconfig -p | grep libcurl
libcurl.so.2 (libc6) => /lib/libcurl.so.2
libcurl.so.1 (libc6) => /lib/libcurl.so.1
libcurl.so (libc6) => /lib/libcurl.so

It appears that the script which installed php did not run the ldconfig utility to update the cache. This was resolved by running ldconfig manually.

[mylogin][~]$ ldconfig -v

My system has library files for libcurl in
/usr/local/lib
/usr/local/phplibs/lib
/ftp/usr/lib
and the version I built myself in /usr/home/mylogin/apps/bld/curl-7.16.0/lib/.libs and /usr/mylocal/lib

so the cache now has the following entries
[mylogin][~/apps/dl]$ ldconfig -p | grep libcurl
libcurl.so.4 (libc6) => /usr/mylocal/lib/libcurl.so.4
libcurl.so.3.0.0 (libc6) => /usr/local/lib/libcurl.so.3.0.0
libcurl.so.3 (libc6) => /usr/local/lib/libcurl.so.3
libcurl.so.2 (libc6) => /lib/libcurl.so.2
libcurl.so.1 (libc6) => /lib/libcurl.so.1
libcurl.so (libc6) => /lib/libcurl.so
libcurl.so (libc6) => /usr/mylocal/lib/libcurl.so
libcurl.so (libc6) => /usr/local/lib/libcurl.so

Note that the files from phplibs are not included directly (the libraries in /usr/local/bin are actually symlinks to phplibs) and that there are entries for /lib (which is itself a symlink to /ftp/usr/lib). I also edited /etc/ld.so.conf to include the directroy /usr/mylocal/lib.

I have just spent ages trying to resolve this problem, digging deep into openssl, certificates, PEM and the wonderful world of encryption, only to find that the answer was staring me in the face! Just goes to show how important it is to enter the right search terms into Google....

I have the following entry in my .fetchmailrc file
poll secure.server with proto POP3
user username@myisp.com there with password xxxx is localname here smtphost mydomain.com keep ssl sslcertck sslcertpath "/usr/local/ssl/certs"
Replace secure.server, username@myisp.com, xxxx, ,localname, mydomain.com as required and enter the correct path to your .pem files and hashes.

Everytime I tried to connect to the server, I got the following output

[mylogin][~]$ fetchmail -kv secure.server
fetchmail: 6.3.5 querying secure.server (protocol POP3) at Tue Oct 31 07:41:02 2006: poll started
fetchmail: getaddrinfo("secure.server","pop3s") error: Servname not supported for ai_socktype
fetchmail: Try adding the --service option (see also FAQ item R12).
POP3 connection to secure.server failed: No such file or directory
fetchmail: 6.3.5 querying secure.server (protocol POP3) at Tue Oct 31 07:41:12 2006: poll completed
fetchmail: Query status=2 (SOCKET)
fetchmail: normal termination, status 2

I thought that maybe the problem was with the certificate for secure.server (in my case secure.cnc.net) as it could not be validated - it uses Authority Information Access (AIA) to resolve its root certificate using OCSP - URI:http://ocsp.verisign.com. This was a red herring and threw me off on a wild goose chase. The real problem was this error
getaddrinfo("secure.server","pop3s") error: Servname not supported for ai_socktype

This means that the service pop3s is not defined in /etc/services and that neither fetchmail nor openssl know which port to connect to. As soon as I added these lines to /etc/services, everything proceeds as expected (I still have to resolve the OCSP problem)

pop3s 995/tcp
imaps 993/tcp
ldaps 636/tcp

Here is the updated output from fetchmail

fetchmail -kv secure.server
fetchmail: 6.3.5 querying secure.server (protocol POP3) at Thu Nov 2 07:50:58 2006: poll started
Trying to connect to xxx.xxx.xxx.xxx/995...connected.
fetchmail: Issuer Organization: RSA Data Security, Inc.
fetchmail: Unknown Issuer CommonName
fetchmail: Server CommonName: secure.server
fetchmail: secure.server key fingerprint: 96:C6:81:FF:A7:22:2F:6D:F5:60:F8:8F:CE:2D:F0:5F
fetchmail: POP3< +OK POP3 Server Ready.
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR Unknown command
fetchmail: Unknown command
fetchmail: Repoll immediately on username@myisp.com@server.myisp.com
Trying to connect to xxx.xxx.xxx.xxx/995...connected.
fetchmail: Issuer Organization: RSA Data Security, Inc.
fetchmail: Unknown Issuer CommonName
fetchmail: Server CommonName: secure.server
fetchmail: secure.server key fingerprint: 96:C6:81:FF:A7:22:2F:6D:F5:60:F8:8F:CE:2D:F0:5F
fetchmail: POP3< +OK POP3 Server Ready.
fetchmail: POP3> USER username@myisp.com
fetchmail: POP3< +OK Password required for username@myisp.com.
fetchmail: POP3> PASS *
fetchmail: POP3< +OK username has 0 message(s) (0 octets).
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for username@myisp.com at secure.server
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Pop server at illustrious signing off.
fetchmail: 6.3.5 querying secure.server (protocol POP3) at Thu Nov 2 07:51:00 2006: poll completed
fetchmail: normal termination, status 1