These messages appear after upgrading to PHP 4.4 or PHP 5.1. These PHP versions raise notices about reference usage that older version accepted happily. Only Horde 3.x and the H3 application versions will be fixed to not cause this messages, so either upgrade to the latest versions, or set your error reporting level in PHP to exclude E_NOTICE level messages.
E.g. in php.ini:
error_reporting = E_ALL & ~E_NOTICE
The Netscape error message, "Document contains no data", only tells you that nothing was sent from the web server to the browser. In other words, something went quite wrong, yet you've no idea what.
In order to get an idea of what really happened, take a look in the web server's error log, in which more verbose errors should be found. There is a good chance that the error is caused by omitting IMAP support from PHP; you can check whether that is the case by examining your server configuration with a PHP script such as the following:
<?php phpinfo(); ?>
Don't confuse PHP's IMAP support with Apache's mod_imap, which refers to image maps.
[IMP 2.2]: Occasionally, the following message will be produced upon login or logout:
Database error (HordeDB): Invalid SQL: INSERT INTO active_sessions VALUES ('562493df1fa64bc81db7b0deb86fc019','HordeSession', '70ee728055533b7ad9fc0bacfb8ecde01718b97968eb65bc79b418d12c0dc0e9') Database error (HordeDB): Session: freeze() failed.
This is produced by a race condition in PHPlib. When two pages try to update the session table at once, the update can sporadically fail. This is more likely to happen at logout from IMP (due to the multiple framesets) than in other use. Charles Wright came up with a patch against PHPlib which should fix this for MySQL users.
Kari Asikainen reports that using PostgreSQL in place of MySQL, or downgrading from PHP 4.0.2 to 4.0.1pl2, eliminates the condition as well.
[IMP 2.2]: This error is caused by an incorrect PHPlib configuration. Make sure that the appropriate section for your chosen storage class is fully uncommented in the local.inc file in your PHPlib directory. Frequently, during configuration, the HordeCT part of the PHPlib configuration (located below the HordeDB section for your storage class) is accidentally left commented out.
This error is the result of a bug in Internet Explorer. Stuart suggests that the following commands (executed on the Windows system on which Internet Explorer is installed) will solve the problem:
regsvr32 c:\windows\system32\actxprxy.dll regsvr32 c:\windows\system32\shdocvw.dll
The FAQ maintainer has not tested the above! Make sure you have a backup of your system before playing with deep Windows magic.
This error occurs when IMP is configured to use MySQL, but PHP was not built with support for MySQL. Rebuild PHP, ensuring that MySQL support is compiled in, and that the line
extension = mysql.so
appears in your php.ini (or php3.ini in PHP version 3).
This error occurs when PHP is not compiled with gettext support. As of Horde 2.0, PHP needs to be compiled with gettext support. Rebuild PHP with the --with-gettext option to configure, or if using RPM's install the php-gettext RPM.
This error most often occurs when IMP tries to use a folder name with an ampersand (&) in it. The easiest solution is to rename the folder to something without an ampersand in it (on the server, or with a different IMAP client).
The error can also occur if IMAP support has not been compiled into PHP. Ensure that your PHP installation supports IMAP.
This error is another symptom of the ampersand question described in the section above.
This error is the result of using IMP without compiling IMAP support into PHP. Be sure that your PHP installation supports IMAP, and rebuild it with the --with-imap flag to configure if it does not (or install the php-imap RPM in an RPM installation).
This error is caused by a bug in older versions of PHP. Upgrade to the current version of PHP, or if you must stay with PHP3, use version 3.0.18.
If IMP produces an error similar to
Warning: PostgresSQL query failed: ERROR: attribute 'val' not found in db_pgsql.inc on line 52 Database error: Invalid SQL: SELECT val FROM active_sessions WHERE sid = '2009f5dd0a3579a38eb0dfb7b9bd2c6f' AND name = 'HordeSession' PostgreSQL Error: 1 (ERROR: attribute 'val' not found ) Session halted.
the usual cause is not a missing attribute nor invalid SQL, but a failure to successfully authenticate with the database. Check your PostgreSQL logs for authentication errors, and make sure you can log in to the database manually using psql with the Horde username and password.
[Horde 1.2]: This error occurs when PHPlib is missing from the PHP include path. Make sure you have followed the instructions in the README file in your PHPlib directory.
This error is often the result of using incompatible versions of Horde and IMP. The appropriate Horde version to use with a given version of IMP is that with a version number one less than IMP's; for instance, IMP 2.2-pre13 used Horde 1.2-pre13, and IMP 3.0 uses Horde 2.0.
Information on choosing the appropriate IMP version for your site can be found in Section 3.2.1
This error usually results from a bug in PHP version 3.0.17. Use version 3.0.18 instead, or upgrade to PHP4.
This error occurs on Red Hat 7 systems, and results from a bug in Red Hat's php-4.0.4pl1-3 RPM. Update your PHP to the latest available from Red Hat.
[Horde 1.2]: Horde ships with its own customized (read: fixed) version of PHPLIB (the horde/phplib directory). You must use that version of PHPLIB; it is the only version that is supported, and most of the other versions of PHPLIB will not work.
This particular error is a sign that Horde is finding a version of PHPLIB other than the one that ships with it. Make sure that session.inc has version 1.1.2.x in the Id tag at the top. Also make sure that your PHP include_path and auto_prepend_file are set properly so that Horde is finding the correct instance of PHPLIB.
On some systems (commonly Solaris and FreeBSD), the upload_tmp_dir setting in php.ini (PHP 4.x) or php3.ini (PHP 3.x) must be set to /var/tmp.
[Horde 2.0]: This error occurs when PHP is not compiled with gettext support. As of version Horde 2.0, PHP needs to be compiled with gettext support. Rebuild PHP with the --with-gettext option to configure, or if using RPM's install the php-gettext RPM. (_() is a synonym for gettext() in PHP.)
[Horde 1.2]: The IMP setup script changes the permissions on the test.php3 script so that it can't be run. This increases the security of your web server by not revealing to intruders information about how PHP is compiled/configured. To use the script while setting up Horde, PHPLIB, or IMP, add read permission for all users to the script:
chmod a+r horde/test.php3
Remember to remove read permission (chmod a-r) from the file when you have finished testing.
[Horde 2.x]: You are using too old a version of PHP which doesn't support some needed functions such as the quote() function. Upgrade to a supported version of PHP.
[Horde 2.x]: Your PHP PEAR implementation is missing the PEAR Log package. This is a common problem with the PHP 4.2.1 PEAR for example. You can install it via the network if you have a standalone php/pear command. See the file horde/docs/INSTALL for more information on how to install the required PEAR packages this way. Otherwise you can download the Log package (e.g. from http://pear.php.net/get/Log) and manually install them inside your PEAR directory. You may also need to install the modules Mail_Mime and Net_Socket as well.
For more detailed instructions on installing PEAR modules, see the PEAR documentation at http://pear.php.net/manual/.
[Horde 2.x]: After the release of Horde 2.1, the isWarning() function was removed from PEAR, resulting in this error when using a PHP/PEAR released after Horde 2.1 was released. Possible solutions are:
The same problem exists in some other Horde applications also (e.g. in Kronolith 1.0). The solution is the same (e.g. upgrade to a newer Kronolith version, remove the isWarning() calls, downgrade PEAR).
[Horde 2.x]: You enabled output compression in both your php.ini configuration file and in your horde configuration file (either horde/config/horde.php or horde/config/conf.php). Disable it in one of these two locations.
[Horde 2.2]: This is a bug in Horde 2.2 when used without php mcrypt support. Either upgrade to Horde 2.2.1, or install the mcrypt php extension.
Either recompile PHP without the --enable-memory-limit option, or increase the value of memory_limit in your php.ini file.
Testing your webserver is straightforward: place a file containing some HTML (or even just some text) in the directory in which it expects to find its data (in Apache, DocumentRoot), and make the file world-readable. Start up the webserver if it is not already running, and in your browser, load
http://hostname.example.com/filename
(substituting the name of the server and the filename as appropriate). If you see the contents of the file, your web server is running. If you receive an error, check your web server's error log to see what went wrong.
The simplest way to test PHP is to create a file, phpinfo.php3, somewhere under your web server's document root, with the following contents:
<?php phpinfo() ?>
Upon accessing it with a browser, you should be presented with a summary of your PHP configuration. If you see the program text itself, your web server does not know to interpret the file with PHP.
[Horde 1.2]: Horde includes a PHP program which will test both your Horde and PHPlib installations. If you have horde installed in the usual location, point your browser at
http://hostname.example.com/horde/test.php3
Verify the following from the information test.php3 offers:
[Horde 2.0]: Horde includes a PHP program which will test both your Horde and PHP installations. If you have horde installed in the usual location, point your browser at
http://hostname.example.com/horde/test.php
Verify the following from the information test.php offers:
This page also may have links to test pages for other installed modules, and/or links to other PHP information pages available.
The simplest way to test an IMAP server is to send mail to an account on the IMAP server, and then use a standard IMAP client like Netscape Mail, Outlook Express, PINE, mutt, or Eudora Pro to read the mail.
If you don't have a standard IMAP client handy, or if a standard client fails, you can telnet to port 143 of your IMAP server and try the following exchange (where "normal" server responses are emphasized):
* OK imap.example.com IMAP4rev1 v12.264 server ready
0 login yourusername yourpassword
0 OK LOGIN completed
0 logout
If you don't get OK LOGIN, then your server is probably misconfigured (unless you are using a specific authentication module such as Kerberos, in which case you will probably have to test it with a real IMAP client or the mtest program included with the UW-IMAP c-client distribution).
The most straightforward way of testing your database is to create the Horde databases themselves; if the creation proceeds without error, then the database is probably functioning normally.
You can also use the following code, contributed by <chowes@ics.bc.ca>:
<HTML> <BODY> This is a test: <?php function test() { if (!($db = mysql_pconnect(localhost,root,yourpassword))){ return 1; } if (!($imp = mysql_create_db(testdb, $db))) { return 2; } if (!($imp = mysql_select_db(testdb, $db))) { return 3; } if (!($result = mysql_db_query(testdb, "create table testtest ( test char(60))", $db))) { return 4; } if (!($result = mysql_db_query(testdb, "insert into testtest values ('hello world!')", $db))) { return 5; } if (!($result = mysql_db_query(testdb, "select * from testtest", $db))) { echo "$result";return 6; } if (mysql_num_rows($result)>0) echo (mysql_result($result, 0, 0)); if (!($result = mysql_db_query(testdb, "delete from testtest", $db))) { return 7; } if (!($imp = mysql_drop_db(testdb, $db))) { return 8; } return 9; } $r = test(); echo "<BR>result code = $r"; ?> </BODY> </HTML>
Then, load the file with your browser. It will create a database, a table, and a row; put data into the row; then delete the row, the table, and the database. If successful, the output will read
This is a test: hello world! result code=9
If it does not, at least you can see where it breaks, by matching the result code with the return statement in the program; the line on which the matching return statement lies is the one which failed. For instance, if result code=1, then mysql isn't running, or a bad host/username/password has been entered.
Jason Haar reports that if you are using Microsoft Exchange as your IMAP server, enabling the server's "fast download" feature causes Exchange to guess at the size of attachments, leading to incomplete or missing attachment information. Disabling "fast download" in Exchange solves the problem (as does switching to a more robust IMAP server).
David Fuchs reports that PHP 3.0.14 can cause every message in a mailbox to claim to have attachments that do not exist. Upgrading to a more recent PHP will solve this problem.
If, in messages sent from IMP, part of the headers of messages are appearing in the message body, check the file horde/imp/config/header.txt, which contains user-specified headers. If that file contains a blank line, then anything following that blank line will become body text (since the delimiter between headers and body in an email message is a blank line).
[IMP 2.2]: The most common problem that results in users being unable to access their mail folders is a misconfigured
$default->folders
in horde/imp/config/defaults.php3. That variable should be set to the location of a user's personal folders, often "mail/" or "Mail/". It must have the trailing slash.
[IMP 3.x]: There are several settings which can influence this:
[IMP 2.2]: If IMP is unable to send mail, first check to make sure that Sendmail (or your Sendmail replacement) is located in the same place that the variable
$default->path_to_sendmail
in horde/imp/config/defaults.php3 is telling IMP to look. If it is there, make sure you can send mail with it with the following Unix command:
echo testing | /usr/bin/sendmail your@email.address
replacing /usr/bin/sendmail with your Sendmail path and your@email.address with your email address. You should receive a (mostly empty) email address, or an error message, almost immediately.
If Sendmail works from the command-line but IMP still refuses to send mail, you may need to turn off PHP's Safe mode, with the following setting in your php.ini (or php3.ini in PHP version 3):
safe_mode off
Before doing that, be sure to read the Security chapter of the PHP Manual.
[IMP 3.x]: If when you press the Send button in the compose window it simply returns the same compose window's contents and no mail is sent, then check that you have PHP file uploads enabled. This is done by setting
file_uploads=On
in your system's php.ini (PHP 4.x) or php3.ini (PHP 3.x) file.
If you are using SMTP rather than a local Sendmail (or equivalent) binary, check that you have set the variable
$conf['mailer']['type'] = 'smtp';
in horde/config/horde.php, and that you have set the smtphost value in horde/imp/config/servers.php for your server entry to the correct smtp host value. Note that this smtphost value will override any existing value for $conf['mailer']['params']['host'] set in horde/config/horde.php.
If you are using a local Sendmail binary, first check to make sure that Sendmail (or your Sendmail replacement) is located in the same place that the variable
$conf['mailer']['params'] = array('sendmail_path' => '/usr/lib/sendmail');
in horde/config/horde.php is telling IMP to look. If it is there, make sure you can send mail with it with the following Unix command:
echo testing | /usr/bin/sendmail your@email.address
replacing /usr/bin/sendmail with your Sendmail path and your@email.address with your email address. You should receive a (mostly empty) email message, or an error message, almost immediately.
If Sendmail works from the command-line but IMP still refuses to send mail, you may need to turn off PHP's Safe mode, with the following setting in your php.ini file:
safe_mode off
Before doing that, be sure to read the Security chapter of the PHP Manual.
[IMP 2.2]: If the Compose window seems too small, first try this setting in your horde/imp/config/defaults.php3:
$default->screen_size = "large";
Keep in mind that "large" may be too large for users with low-resolution displays. Some suggest changing the value of
$default->compose_body_cols
to something larger than the default of 80, but since 80-column text is the standard for Internet mail messages (even though you can make your Windows or MacOS mail windows larger!), it is strongly discouraged.
The file horde/imp/locale/languagecode/openwin.lang also contains some window-size parameters, but is meant more for developer fine-tuning than for site-by-site configuration.
Certain versions of Netscape have a bug which makes IMP screens take a very long time to load over an SSL connection while not being particularly slow over an unencrypted connection. The bug is with Netscape's handling of keep-alive connections. In order to prevent the browser from having to make one connection to the web server for every file it needs, the HTTP protocol provides "keep-alive", which allows the browser to use one connection to transfer multiple files. Unfortunately, over an SSL connection, Netscape does not notice if the server closes the keep-alive connection (as servers do after a certain period of time), and continues to try to make requests over the now nonexistent connection. Since this happens towards the end of rendering the page in the browser, missing image files is a common symptom.
It is not clear which versions of Netscape on which platforms suffer from this bug; extensive testing on MacOS showed that any release of Netscape 4 was capable of slowing down as described above, but not all installations would suffer. The bug also has been known to trigger under Windows NT.
Unfortunately, the only solution to this problem (other than not using Netscape, or not using SSL) is to disable keep-alive on the webserver. In apache, the following entry in /usr/local/apache/conf/httpd.conf will turn keep-alive off:
KeepAlive Off
This will cause a performance degradation, as browsers will now have to make multiple connections where previously a single connection sufficed. Be sure to monitor performance after making this change to determine if the performance degradation is too severe to maintain. (On a Digital AlphaServer DS20 with two 500MHz processors and 1GB of RAM, the performance change was unnoticeable.)
Some versions of Microsoft Internet Explorer only understand 40- and 128-bit encryption, but not 56-bit. If a user has a weak-encryption version of Internet Explorer, 128-bit encryption will also be unavailable, but Apache will try to offer 56-bit, and the transaction will fail.
To tell Apache to only offer 40- or 128-bit encryption, replace the SSLCipherSuite directive in your httpd.conf file with:
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
When you restart your webserver, it will only offer 40- and 128-bit encryption, solving the problem. Note that this means that browsers which only support 40- and 56-bit encryption (such as weak-encryption versions of Netscape) will fall back to 40-bit as well.
Individual users can solve this problem without having to alter the Apache configuration by obtaining a version of Internet Explorer with 128-bit encryption enabled from Microsoft.
When IMP returns to the login screen despite not being told to log out, it is usually the result of your session timing out because you were idle for too long. This is a feature, designed to prevent unauthorized use of an IMP session if you walk away from their computer leaving the browser running.
You may be able to adjust the timeout if you determine it is too short. In PHP4, timeout length is controlled by the following variables in your php.ini file:
session.cookie_lifetime session.gc_maxlifetime session.gc_probability
If it is happening too soon to be a timeout, you may have used the file php.ini-optimized or php.ini-recommended from the PHP distribution to configure PHP. Using the php.ini-dist file instead may prevent the erratic logouts.
If this happens for all users -- or if IMP logins have never succeeded -- check the syslog and the IMAP server log on the mail server, and verify that there are no access controls (such as hosts.allow rules) blocking IMAP connections from the IMP web server (which might be localhost).
If characters such as ', ", and \ are producing extra backslashes ("\") in IMP, you probably have one of the following settings in your php.ini (or php3.ini in PHP version 3):
magic_quotes_gpc = on magic_quotes_runtime = on magic_quotes_sybase = on
All magic_quotes options must be disabled for IMP. Remember to restart your web server after changing php.ini settings.
If IMP refuses to mark a message as read after you have read it, you probably have a buggy version of the UW-IMAP c-client library. Upgrading to the current version (and rebuilding PHP against it) should resolve the problem.
No matter how broken Horde or IMP might be, there are precisely zero conditions in which it should be able to induce a segmentation fault ("core dump" or "segmentation violation" or possibly even "bus error") in Apache or PHP. If such a condition occurs, please inform the developers of PHP by making an entry in their bug database.
There is a great explanation of how to debug where the segmentation fault occurs at http://bugs.php.net/bugs-generating-backtrace.php which may be of help.
While headers in outgoing messages such as
X-Authentication-Warning: nobody set sender to username with -f option
may sound ominous, they're only pedantically noting what took place when the message was sent. IMP, running as the user "nobody", set the envelope sender (not the From: header!) of the message to "username", using Sendmail's -f option. This makes the message appear to have originated with "username", not "nobody", so that bounces will end up in the right place.
This can be disabled with Sendmail by removing the authwarnings option from the sendmail.cf file or by adding the web server account to the list of trusted users in the sendmail.cf or submit.cf file; consult your Sendmail documentation for details.
Incorrect configuration causes IMP to hang upon login until the IMAP server times out, producing an error. Occasionally this will only happen for certain users on a particular server. It is usually caused by mis-specifying the name of the directory in which mail folders are found. In IMP 2.2, check the variable $default->folders in horde/imp/config/servers.php3, or the value as specified by the user if the user can specify folder information at login. In IMP 3.x check the folders and namespace values in horde/imp/config/servers.php or the value as specified by the user if the user can specify folder information at login.
Since everything under this directory is traversed by the IMAP server in order to generate the folder list, accidentally setting this to the user's home directory -- or something higher in the filesystem -- can cause the process to take too long to generate the entire list, leading to IMAP timeouts.
Addresses in the headers such as the above are produced by PHP, not IMP (via the IMAP c-client library), and are most often the result of a user using semicolons instead of commas to separate addresses, such as is done in MS Outlook Express. Discussions on the mailing list tend to conclude that the solution to this is "well, don't do that, then", since both commas and semicolons have their own meanings in the Internet message format standard, RFC 822.
The UW-IMAP server stores the state of a mailbox as a specially-formatted mail message in the mailbox, with the header
Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
The messages do not appear when the mailbox is accessed over IMAP, and appear only once when the mailbox is accessed directly. When accessing the mailbox over POP3, however, that message is downloaded repeatedly, since each time the mailbox is accessed with IMAP, the message is marked as unread.
The qpopper POP3 server for Unix features a compile time option, --enable-uw-kludge, which will cause the server to refrain from offering the IMAP state message to a POP3 client. The current beta version of the UW-IMAP server is reported to no longer use the state message, nor do any other IMAP servers.
[IMP 2.2]: For the Cyrus and Courier-IMAP imap servers, this is often caused by an incorrect setting in horde/imp/config/defaults.php3. Make sure you have the following:
$default->personal_folders = 'INBOX.';
The trailing dot is required (and its omission is usually the culprit!).
See also question 5.3.4 (for any version of IMP).
IMP uses the value of the upload_tmp_dir configuration variable to ensure that attachments are safely uploaded to the web server. If this variable is undefined, IMP is unable to locate the uploaded attachment. To define your upload directory, add something like the following to your php.ini file:
upload_tmp_dir = /var/tmp
Remember to restart your web server in order for this change to take effect.
//Special note for some Apache 2.0 users://
If you are running Red Hat or Fedora Core Apache 2.x RPMS, or a Red Hat/Fedora based distribution, you should have a separate /etc/httpd/conf.d/php.conf file. Look inside it for a set of text like this:
SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 524288 <---- This was the problem on mine
Change the LimitRequestBody 524288 line to something larger. It is the maximum allowed size of a httpd request in bytes. You may need to set this about twice as large as the desired size to account for encoding of submitted data.
From http://lists.horde.org/archives/imp/Week-of-Mon-20030203/029747.html.
This is a known problem with PHP 4.2.2/4.2.3 and certain versions of the UW IMAP c-client. If using these PHP versions, either downgrade to UW IMAP c-client 2001a or upgrade to PHP 4.3.0.
This is a bug in the code that has since been fixed. The error is in turba/lib/api.php at about line 93. The incorrect and correct lines are:
INCORRECT: if (PEAR::isError($res) || count($res) > 0) { CORRECT: if (PEAR::isError($res) || $res->count() > 0) {
This means you have a missing or misconfigured socket and/or protocol parameter value in the params block(s) in /horde/turba/config/sources.php.
Unless you are trying to use unix sockets rather than tcp/ip connections, set the socket value to '' (meaning no value), and/or set the protocol value to 'tcp'.
When adding new attribute names in the sources.php map section for ldap servers, make sure all the attribute names are completely lowercase. Also make sure that all attributes you add to sources.php are also added to attributes.php. Finally, make sure your ldap ACL's are set correctly to allow them to be viewed.
The 'objectclass' entry for LDAP address book definitions in turba/config/sources.php is respected in Turba 1.2 but wasn't in earlier versions. Set it to use a correct value for your LDAP structure.
Turba has a system of defining what is in a directory or address book which is necessarily complicated by reason that it is flexible enough to map to pretty much anything with no code changes, only configuration file tweaks.
In turba/config/sources.php, for every backend that you use in Turba, you configure a map. The map defines a mapping between whatever fields exist in the backend directory and what Turba calls those fields and also what kind of data Turba treats them as containing. So if the contact_email field in a database table is an email address, you could tell Turba to map 'email' => 'contact_email'.
However, Turba needs to then know what 'email' or 'name' are. They're defined in turba/config/attributes.php, which is the set of attributes that any given Turba installation understands. The attributes.php file defines the label for a field and also what kind of data it is - a string, an email address, an enumeration of several options, etc.
So, back to the problem: you have some attributes in your map that Turba doesn't know about. In sources.php, there's probably a line something like:
'businesscategory' => 'backend_field_bus_cat',
But there is no 'businesscategory' attribute in your attributes.php. You need to either add an attribute entry, or remove that field, or map it to something else that Turba already knows about.
In some versions of Turba, the default sources.php file included an example that used attributes that weren't in the default attributes.php file and hence could cause this error. This has since been fixed for newer releases.
This usually means one of the following:
Some web servers do not support PATH_INFO, or have it disabled by default, in which case this problem will arise. Try to disable PATH_INFO usage by setting $conf['options']['use_path_info'] to false in horde/chora/config/conf.php.