Rolling Resource

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

Westhost limit the size of your mailbox to 20MB, which is a bit puny these days. However, the reason that they do this is that they keep all your mail in a single file, so every time you check your email, you have to read the whole file starting from the top. This places a large load on the server if you have a huge file.

You can override this by manually editing the file /etc/features. This file contains lines of the form
username:mail=20,ftp=-1,description=Account details
Just change the mail=20 as you see fit to specify the size of your mailbox in Megabytes (MB), so for 60MB you would have
username:mail=60,ftp=-1,description=Account details

NOTE: Westhost will automatically archive and delete mailboxes over 75MB as described below

Large Mailboxes

Introduction

Your mailbox on the server is a single text file containing all of your e-mail, using the industry standard "mbox" format. Anytime you log into the incoming mail server to check your e-mail the mail server needs to read this file so your e-mail client (e.g. Outlook, Eudora, Thunderbird) can determine whether or not there is any new e-mail to download.

As the size of your mailbox increases, it takes more and more time to read that file when you check your e-mail. Large mailboxes keep the server busy for extended periods of time, needlessly degrading server performance for everything else. This translates into sluggish websites, delayed e-mail, and general unresponsiveness.

Archiving Large Mailboxes

In order to keep server performance high, we perform scans every other month and archive mailboxes that are larger than 75 megabytes. Archived mailboxes are compressed using the GNU 'gzip' program and are only kept until the next scan (at which point old archives will be automatically removed). If you ever need to have your archived e-mail restored please contact support for assistance.

Clearing Out a Large Mailbox

To clear out a large mailbox you will need to delete old e-mail. The easiest way to see what e-mail is being stored on the server is by checking your e-mail by logging in at http://webmail.westserver.net. From here you will be able to selectively delete any e-mail you no longer wish to keep. Deleting an e-mail off of the server will not effect any copies of a message you have already downloaded to your computer through your e-mail client.

Preventing Large Mailboxes

The best way that you can prevent your mailbox from growing too large is to configure your e-mail client to automatically remove e-mail from the server as it is downloaded. Nearly every e-mail client does this by default for you, unless you have specifically configured it not to. If needed, you can consult the help files for your particular e-mail client to learn how to change this setting.

We also strongly suggest only using a catch-all e-mail address when absolutely necessary. Spammers will try to guess e-mail addresses using your domain name. When you have a catch-all e-mail address they will always be guessing correctly, thus greatly increasing the amount of e-mail delivered to your mailbox. If you need to receive e-mail by a variety of names (e.g. sales@example.com, info@example.com, etc.) we advise you either use e-mail aliases or to setup separate mailboxes for each address. You can make all of these changes by logging into your Control Panel (Site Manager) at http://www.yourdomain.com/manager/ (make sure to replace yourdomain.com with your actual domain name) and clicking on E-mail / FTP Management on the top horizontal navigational bar.

Step 1 - Download source

The first thing we need to do is download the source file from GnuPG.  I like to download the files directly to my server rather than downloading them to my PC and then uploading them to my server, so lets use a SSH session.  There are plenty of SSH Clients available, but PuTTY is available for free and does the job.  Instructions for configuring PuTTY for Westhost are available here.  Once you have logged in, create a directory to download your files to (for example, apps/dl) using the mkdir
[mylogin][~]$mkdir apps
[mylogin][~]$mkdir apps/dl

The files we need are only available via FTP from GnuPG.  If you clicked on the link to their site above, you will have found the latest version - at the time of writing this is 1.4.5.  Hover your mouse over the FTP link and you will find that the file we want to download is located at ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.5.tar.bz2, that is to say the file gnupg-1.4.5.tar.bz2 is located on the server called ftp.gnupg.org in the directory gcrypt/gnupg Follow the example below to download your own copy (user input is in bold).  It is good practice to download the signature file gnupg-1.4.5.tar.bz2.sig as well. 

If you prefer, you can download the gzipped file gnupg-1.4.5.tar.gz instead of gnupg-1.4.5.tar.bz.  You do not need both sets, although I download them in the example below.  GZip is just an older piece of software.  The command to extract the files would be gunzip instead of bunzip2

Step 2 - Checking the download

Now that we have the source files on our server, we need to check that they have not been tampered with.  The simplest way is to issue the command bunzip2 -t gnupg-1.4.5.tar.bz2

[mylogin][~/apps/dl]$ bunzip2 -tv gnupg-1.4.5.tar.bz2
gnupg-1.4.5.tar.bz2: ok

However, this only checks that the archive is not corrupt.  You really need to check the file's digital signature, but we don't have any means to do that yet.  We can verify the checksum but GnuPG only publish the SHA1 checksum for the code and we do not have sha1sum installed on our server.  However, I can reveal that the MD5sum is

811525965b4c0987e6418a7729a6444d gnupg-1.4.5.tar.bz2

If you save this text to the file gnupg-1.4.5.tar.bz2.md5, then enter md5sum -c gnupg-1.4.5.tar.bz2.md5 on the command line, you should get this response

[mylogin][~/apps/dl]$ md5sum -c gnupg-1.4.5.tar.bz2.md5
gnupg-1.4.5.tar.bz2: OK

If there was a problem with your download, you will get the following error message when testing the archive

bunzip2: gnupg-1.4.5.md5: data integrity (CRC) error in data

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

Step 3 - Other libraries

We need to download and install the libcurl, libiconv and gettext libraries before we can build GnuPG.  Also, since we do not have root access at Westhost, we need to tell all Linux packages to install to a different directory other than /usr/local.  We do this by specifying

./configure --prefix=/usr/mylocal
NOTE: Create the directory /usr/mylocal if it does not already exist

libiconv and gettext depend on each other, so we need to build libiconv then gettext and the rebuild libiconv.

Build libcurl

wget http://curl.haxx.se/download/curl-7.16.0.tar.bz2
wget http://curl.haxx.se/download/curl-7.16.0.tar.bz2.asc
bunzip2 -c curl-7.16.0.tar.bz2 | tar x
cd curl-7.16.0
./configure --prefix=/usr/mylocal
make
make install
cd ..


Build libiconv

wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.11.tar.gz
wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.11.tar.gz.sig
gunzip -c libiconv-1.11.tar.gz | tar x
cd libiconv-1.11
./configure --prefix=/usr/mylocal
make
make install
cd ..


Build gettext

ftp mirrors.usc.edu
 anonymous
 anon@
 cd pub/gnu/gettext
 mode image
 passive
 get gettext-0.16.tar.gz
 get gettext-0.16.tar.gz.sig
 quit
gunzip -c gettext-0.16.tar.gz |tar x
cd gettext-0.16
./configure --prefix=/usr/mylocal
make
make install


Rebuild libiconv

cd ../libiconv-1.11
make distclean
./configure --prefix=/usr/mylocal
make
make install
libtool --dry-run --finish /usr/mylocal/lib
libtool --finish /usr/mylocal/lib
cd ..


Step 4 - Creating the Executable

bunzip2 -c gnupg-1.4.5.tar.bz2 |tar x
cd gnupg-1.4.5
./configure --prefix=/usr/mylocal
make
make install


Once you have built GnuPG, you will need to create a few links as our directory is not in the PATH.

ln -s /usr/mylocal/bin/gpg /usr/local/bin/gpg

Alternatively, edit the PATH definition in /.bashrc to include /usr/mylocal/bin

You will also need to copy the configuration file
mkdir ~/.gnupg
cp -p /usr/mylocal/share/gnupg/options.skel ~/.gnupg/options