Racker Hacker

If you’ve used newer versions of Horde with Plesk, you have probably noticed the news feed that runs down the left side of the screen. Depending on the types of e-mails you receive, you may get some pretty odd news popping up on the screen.

Luckily, you can remove the news feeds pretty easily. Open the following file in your favorite text editor:

/usr/share/psa-horde/templates/portal/sidebar.inc

Once the file is open, drop down to line 102 and comment out the entire if() statement (lines 102-117).

NOTE: If you upgrade Plesk, this change will most likely be reversed.

If you’ve ever worked on a server that was being overworked (I know I have), you might see sendmail throw out a message like this one:

Jan 9 14:15:49 mail sendmail[18184]: rejecting connections on daemon MTA: load average: 70

This is sendmail’s way of trying not to contribute to the already high load placed on the server. Since busy mail servers generally use a lot of disk I/O for the queue, and they may pass mail to other filters (which uses CPU time), the sendmail daemon will refuse to handle mail to help reduce the load.

If you don’t like the values that are currently set, you can change them with the following configuration directives in your sendmail.mc:

define(`confQueueLA', `100')dnl
define(`confRefuseLA', `100')dnl

The confQueueLA defaults to the number of processors in your system multiplied by eight, and the confRefuseLA defaults to the number of processors in your system multiplied by 12. However, it is noted that this default differs between versions as well as distributions.

The two configuration items control when sendmail will process items in the queue only (QueueLA) and when sendmail will stop accepting incoming SMTP connections all together (RefuseLA).

I stumbled upon a server running Plesk 8.2.1 where a certain user could not receive e-mail. I sent an e-mail to the user from my mail client, and I never saw it enter the user’s mailbox. It didn’t even appear in the logs.

After checking the usual suspects, like MX records, mail account configuration, and firewalls, I was unable to find out why it was occurring. Even after a run of mchk, the emails would not be delivered.

I began testing with a telnet connection to the SMTP port:

$ telnet 11.22.33.44 25
Trying 11.22.33.44...
Connected to 11.22.33.44.
Escape character is '^]'.
220 www.yourserver.com ESMTP
HELO domain.com
250 www.yourserver.com
MAIL FROM: test@test.com
250 ok
RCPT TO: someuser@somedomain.com
421 temporary envelope failure (#4.3.0)
QUIT
221 www.yourserver.com
Connection closed by foreign host.

Temporary envelope failure? I was still confused. After reviewing the logs, I found the following line whenever I tried to telnet to port 25 and send an e-mail:

Dec 2 00:15:49 www relaylock: /var/qmail/bin/relaylock: mail from 44.33.22.11:17249 (yourdesktop.com)

It turns out that the customer was using greylisting in qmail with qmail-envelope-scanner. After a quick check of /tmp/greylist_dbg.txt, I found the entries from me (as well as a lot of other senders), and that ended up being the root of the problem.

One of my biggest beefs with Plesk’s e-mail handling is the lack of server-side filtering. Plesk will only allow you to throw away e-mails marked as spam, but this won’t work for me since SpamAssassin marks some mails as spam that actually aren’t. If you set up filters in SquirrelMail or Horde, the filters will only work if you always log into the webmail interface to snag your e-mail.

Luckily, you can do some fancy work with procmail to have the filtering done server-side.

First, make sure procmail is installed on your server, and change to this directory:

/var/qmail/mailnames/yourdomain.com/yourusername/

Inside that directory, drop in a .procmailrc file which contains the following:

MAILDIR=/var/qmail/mailnames/yourdomain.com/yourusername/Maildir
DEFAULT=${MAILDIR}/
SPAMDIR=${MAILDIR}/.Junk/
:0
* ^X-Spam-Status: Yes.*
${SPAMDIR}

Once that file is in place, move the .qmail file out of the way, and replace it with this:

| /usr/local/psa/bin/psa-spamc accept
|preline /usr/bin/procmail -m -o .procmailrc

Please be aware that these changes will disappear if you make any adjustments to your mail configuration within Plesk. To get around this annoyance, just change the file attributes to immutable:

# chattr +i .qmail .procmailrc

Credit for this trick goes to Russ Wittmann.

A few days ago, I stumbled upon a server running qmail with qmail-scanner. The server was throwing out this error when a user on the server attempted to send an e-mail to someone else:

451 qq temporary problem (#4.3.0)

The one thing I love about qmail is its extremely descriptive error messages. Did I say descriptive? I meant cryptic.

Luckily, clamdscan was a bit more chatty in the general system logs:

Nov 12 10:21:17 server X-Antivirus-MYDOMAIN-1.25-st-qms: server.somehost.com119488087677512190] clamdscan: corrupt or unknown clamd scanner error or memory/resource/perms problem - exit status 512/2

Okay, that helps a bit, but this one from /var/log/clamd.log was the big help:

Mon Nov 12 12:20:29 2007 -> ERROR: Socket file /tmp/clamd.socket exists. Either remove it, or configure a different one.

I removed the /tmp/clamd.socket file and clamd began operating properly after a quick restart of the clamd service. This one was pretty easy, but it was not well documented (as I discovered from a little while of Google searching).

If you’re using Plesk 8.0 or later, you can set up Dr. Web to be enabled for all new mail accounts. To do this, you have to create an event handler.

Here’s the steps you will need:

» Log into Plesk
» Click “Server”
» Click “Event Manager”
» Choose “Mail Name Created” next to “Event”
» In the command area, enter /usr/local/psa/bin/mail.sh --update $NEW_MAILNAME -antivirus inout
» Click “OK”

In some situations with dovecot running on your server, you may receive a message from your e-mail client stating that the “connection was interrupted with your mail server” or the “login process failed”. This may happen even if you’ve created the e-mail account, created the mail spool, and set a password for the user.

If you check your /var/log/maillog, you will generally find errors like these:

Oct 7 09:37:45 mailserver pop3-login: Login: newuser [111.222.333.444]
Oct 7 09:37:45 mailserver pop3(newuser): mbox: Can’t create root IMAP folder /home/newuser/mail: Permission denied
Oct 7 09:37:45 mailserver pop3(newuser): Failed to create storage with data: mbox:/var/spool/mail/newuser

Dovecot is telling you that it wants to store some mail-related data in the user’s home directory, but it can’t get access to the user’s home directory. If the home directory doesn’t exist, create it and set the permissions properly:

# mkdir /home/newuser
# chown newuser:newuser /home/newuser
# chmod 755 /home/newuser

If the directory is already there, double check the ownership and permissions on the directory. If filesystem acl’s or filesystem quotas might be in play, be sure to check those as well.

On brand new Plesk 8.2.x installations or on servers that have been upgraded to Plesk 8.2.x, you might run into this error when you attempt to log into squirrelmail after it was installed via RPM:

Error opening /var/lib/squirrelmail/prefs/default_pref
Could not create initial preference file!
/var/lib/squirrelmail/prefs/ should be writable by user apache
Please contact your system administrator and report this error.

No matter what you do to the /var/lib/squirrelmail/prefs/default_pref file, even if you chmod 777 the file, you will still get the error. If you check the /etc/php.ini, you will normally find safe_mode set to on.

;
; Safe Mode
;
safe_mode = Off

Simply change safe_mode to off and reload Apache. If you try to log into squirrelmail again, it should complete successfully. I’ve tested this on Red Hat Enterprise Linux 4:

# rpm -q squirrelmail
squirrelmail-1.4.8-4.0.1.el4

I’ve seen quite a few situations where the Horde login process can take upwards of 45 minutes to log a user into the webmail interface. There’s a few issues that can cause these extended delays, and most of them can be fixed rather easily:

Too many filters / Giant whitelists and blacklists
This is the biggest cause that I’ve seen. Some users will create gigantic white and black lists (upwards of 5,000 is my record that I’ve seen) and this makes Horde compare each and every message in the inbox against these lists upon login. This also applies to filters as Plesk does not use sieve/procmail for mail delivery. Horde is forced to do all of the filtering upon login (in some versions) and this can cause extreme delays.

Mailbox is gigantic
I’ve seen Horde logins take quite a while in mailboxes that are over 500MB in size. If the size of your e-mails is large, and you have a large mailbox with fewer e-mails, Horde can normally work quickly. But, if your inbox is full of tiny e-mails, Horde takes a long time to fully index your mail and display the list (even though it only displays 25-30 at a time).

Too many users logged into Horde simultaneously
In my opinion, Horde’s CPU and memory requirements are too large for a webmail application. I’ve seen 30-40 simultaneous Horde sessions bring a dual-core box with 2-4GB of RAM and SCSI disks to its knees. Consider installing squirrelmail or roundcube webmail for some of your users and urge them to use it instead.

IOwait caused by something else
Sometimes the server can simply be bogged down with other requests from other daemons, and this slows Horde down. Make sure that your MySQL installation is tuned properly, and that users are not abusing scripts running through Apache.

Since AOL sends their users’ traffic through proxy servers, this can cause problems with Horde’s session handling in Plesk. The problem arises when the user’s IP changes during the middle of the session.

You may see an error message in Horde that looks like this:

Your Internet Address has changed since the beginning of your Mail session. To protect your security, you must login again.

You’ll normally have this variable in /etc/psa-horde/horde/conf.php:

# $conf['auth']['checkip'] = true;

You can disable this ip check functionality which breaks sessions for AOL users by setting it to false:

# $conf['auth']['checkip'] = false;