http:// / client /

Information for my clients

This information is here for my clients to use. If you've stumbled on to the page but you're not one of my clients, there's probably not much here for you.

Last updated 2018-03-29

Email issues

Email hosting setup

If you have a domain and want me to handle its email, there is a specific DNS entry (called an "MX record") which needs to be created. If I'm handling your domain's DNS, I will do this for you. Otherwise, you will need to set up this DNS record, with the following values:

Record Type MX
Priority 0
Server Name

Let me know when you have done this, and I will set up the domain and its postmaster mailbox on the server.

Mailbox administration

The "qmailadmin" interface for your domain is accessible using to access qmailadmin.

Note: this address will redirect you to the actual address, which is Feel free to use either address, I just find the first one easier to remember.

Email client setup directions

If I am hosting your domain's email on my server, you will need the directions on this page to set up an email client (such as Thunderbird) to access your mailboxes.


If you wish to use a webmail interface to access your mailboxes, you can use to access the webmail interface. It's not the fanciest interface out there, but it works.

Mail filtering rules

I have written an interface which allows my users to control the filtering of their incoming email. You can use it by visiting

If you're curious, this page has information about the system itself, including instructions on how to set it up on your own qmail server.

Allowing me remote SSH access

If you are my client because I am managing, maintaining, or otherwise accessing your server without physically being in the same room with it, this section is for you.

In order to allow me to remotely access your server via ssh, you first need to make sure your sshd allows logins with public keys. Check and/or edit your /etc/ssh/sshd_config file. You need to make sure it has the following entries:

PubkeyAuthentication   yes
This may be commented out. Since the default is "yes", this is fine. The point is that it cannot be "no".

AuthorizedKeysFile     .ssh/authorized_keys
Some older systems used the name ".ssh/authorized_keys2" instead. If yours is one of them (i.e. if this line already exists and has the other filename) that's fine- you just need to adjust the filename when installing the key (below.)

If this line exists and is un-commented in your sshd_config file, you should make sure that the userid as which you wish me to log in is listed.

In addition, if the userid you wish me to log into is "root", you will need to check this line as well:

PermitRootLogin        without-password
Note that you could also have "yes" here, although it's not as secure. The difference is that "without-password" means that root is allowed to log in, but only if they use an authentication method other than "password". This way if somebody happens to find out what your root password is, they can't use it to ssh into your machine.

I know the phrase "without-password" can be a bit misleading. You should type "man ssh_config" to read more abut this option.

If you had to change the /etc/ssh/sshd_config file, you will need to restart sshd. This is usually done with a command like this...

# /etc/init.d/sshd restart

Adding my ssh public key

After checking the configuration of sshd, you will need to add my current ssh public key to the ".ssh/authorized_keys" file within the home directory of the user you wish me to access. This example shows how to set it up. Note that if your system uses the name ".ssh/authorized_keys2" in the AuthorizedKeysFile line (see above) you should substitute that filename below.

I have changed to a new SSH key as of 2017-11-27, with the private key stored only on a YubiKey 4 which I carry on my keyring. If you have one of my older keys on your server, please remove it, and install the new one instead.

# cd ~userid
Substitute the userid as which you wish me to log in.
# mkdir -f -m 700 .ssh
# cd .ssh
# wget
The file should transfer. If you don't have wget on the system but you do have curl, you can replace "wget" with "curl -O" (that's a capital "o", not a zero) and accomplish the same thing.
# cat sshkey.txt >> authorized_keys
# chmod 600 authorized_keys
# chown uid:gid authorized_keys
Substitute the userid and that user's login group ID as which you wish me to log in.

Accessing files via FTP

If your web site is hosted on my server, this section is for you.

The normal FTP protocol involves the client sending the password to the server, across the internet, in plain text. This means that anybody with a packet sniffer in the right place is able to literally READ your password right off the wire.

Because of this inherent insecurity, I do not, and will not, allow any access to my server using the FTP protocol.

There is a protocol called SFTP, which is part of the SSH protocol suite. My server does allow SFTP access, using the same port number used for SSH logins (in fact, SFTP can happen over the same SSH tunnel which carries your login session.) More programs every day are starting to support it, but not all of them.

If you are using a program which knows how to do FTP, but doesn't know how to do SFTP, all is not lost. There are ways around the problem, depending on your system.

SSL Certificates

If I'm hosting web sites for you, those web sites really need to be encrypted (i.e. served using the https protocol.) In order to do that, the server needs an SSL certificate and the corresponding private key.

If I'm handling your domain's DNS, then I can get these certificates for free, and renew them automatically, using Let's Encrypt.

If your domain's DNS is hosted somewhere else, I can help you get them, but it will be a manual process to get and renew the certificates. The first part of the process is to generate the key and a CSR (Certificate Signature Request). In order to maintain security, I normally generate these things on the server (where the key file has to be anyway), and then you use the CSR to get the actual Certificate.

Either way, the web server has to be manually configured to use the key and certificate, and to set up a non-encrypted redirector so that users who request your site using http:// are automatically redirected to the https:// URL. Talk to me about it and we can go over the details.