• Tech

    Squirrelmail: Attachments download as “download.php” when using 2-byte interface


    When downloading an attachment from the Squirrelmail webmail interface, the downloaded file’s filename remains as “download.php” instead of being renamed to the correct filename. This only happens when a 2-byte character language interface is selected from “Options > Display options”.


    When using a 2-byte language interface, the encoding and decoding of the attachment filename is passed through the i18n.php logic. The particular code detects the users’ CPU platform and passes along the decoding to a function accordingly. The code in “functions/i18n.php” has an error where the CPU detection string uses “Mac_” instead of “Mac”. “Mac_” only applies to MSIE. It is very likely that the programmers of i18n.php has only tested this code using MSIE and not Safari or a Mozilla variant.


    Edit “functions/i18n.php” around line 630. Change:

    strstr($useragent, 'Mac_') !== false) {
    strstr($useragent, 'Mac') !== false) {
    *** This method has not worked consistently throughout version updates. Please make a backup of the original file before proceeding. ***
  • Uncategorized

    Mojibake with Japanese Filenames

    Japanese filenames will cause MOJIBAKE in squirrelmail when POST is used through PHP. You will need to make the following changes to php.ini on a new server.

    mbstring.language = Japanese

    mbstring.http_input = auto

    You may also force, if you wish:

    .internal_encoding = EUC-JP

    but, it is not necessary to do so.

  • Uncategorized

    Mac OS X Server + SquirrelMail: Changing user passwords

    SquirrelMail does not come with the ability to chang user passwords. This is becaus SM is just a PHP based mail client and has nothing to do with the authentication server. Password authentication is done differently on Linux, Mac OS X, and Windows, so there is no default password changing feature. Luckily, SM accepts plugin modules.

    Individuals have come up with password changing modules that interface with LDAP, Merak, MySQL, PAM (poppassd), Courier (courierpassd), Cyrus, and the UNIX shadow password file.

    Unfortunately, there is no plug-in available for CGP’s PWD. 

    Now there is a easy hack to make the Change_passwd plugin module work with Mac OS X’s authentication server.

    ***Update 4/22/2008***

    For Mac OS X servers v. 10.2.x~10.3.x, you can use an open source API called “dspasswd” to interface SM/Change_passwd to the Open Directory password service. For 10.4.x, Apple has included an API called “pwpolicy” that works very well. For this example, we’ll use pwpolicy on 10.4.x.

    0. You will need the appropriate version of the Compatibility plugin already installed.
    1. Download the version of the “Change_passwd” plugin for your version of SM.
    2. Unzip the change_passwd directory into the SM/plugins directory.

    gzip -xzfr change_passwd_x.tar.gz

    3. Open the change_passwd directory. Copy config.php.sample to config.php.

    cd change_passwd
    cp config.php.sample config.php

    3. Edit config.php to point the plugin to the pwpolicy API:

    $overridePathToChpasswd = '/usr/bin/pwpolicy';

    4. Edit options.php. Find and comment out:

    // $cmd = "$overridePathToChpasswd $safe_user $safe_oldpw $safe_newpw";

    Add right after:

    $cmd = "$overridePathToChpasswd -a $safe_user -p $safe_oldpw -u $safe_user -setpassword $safe_newpw";

    5. In v.4.0 of the plugin, there is a typo in functions.php:

    compatibility_check_plugin_setup('change_passwd', array('config.php'));

    should be:

    check_plugin_setup('change_passwd', array('config.php'));

    6. In v.4.0 of the plugin, there is a typo in options.php, line 64:


    should be:


    7. Run SM the configure tool:

    cd /usr/share/squirrelmail

    8. Turn on the change_passwd plugin.

    The plugin will now be available under the Options menu through the webmail interface. Try it out.

    ***Update 11/07/2008***

    To use the change_passwd plug-in, you also need the compatibillity plug-in. The last update to the change_passwd plug-in was in 2004 when the the compatibility plug-in was on version 1.3.

    Alas, the change_passwd plug-in does not work with the newest compatibility plug-in. So far, I have confirmed that the compatibilty plugin works up to 2.0.2.

    I suspect this is because the location of the compatibility patch was change in 2.0.3.

    ***Update 12/29/2008***

    A beta version of the Change Password plugin is available at:

    The beta version 4.2-1.2.8 released on 12/07/05 includes switches for ‘pwpolicy’ in the config.php file and does not require any changes in functions.php or options.php.

    I have confirmed that change_passwd v.4.2b-1.2.8r120705 works with the compatibility plugin 2.0.13.

  • Uncategorized

    Security Update 2008-002 and Mail Services on OS X Server 10.4.11 [by celiawessen]

    Below is an excerpt from the Apple Discussion boards from a post by pterobyte (aka Alex) of osx.topicdesk.com.


    A word of caution before applying Security Update 2008-002 to OS X Server 10.4.11:

    According to this document:
    the security update updates ClamAV to 0.92.1. Which is fine.
    What the document, doesn’t tell is that spamassassin, amavisd and what is worse, configuration files, get overwritten in the process as well (without software actually being updated).

    This has some side effects which unfortunately vary from system to system and configuration to configuration.

    If you never updated ClamAV, spamassassin or amavisd manually check that:
    -/etc/mail/spamassassin/local.cf, /etc/mail/spamassassin/init.pre and /etc/amavisd.conf didn’t get overwritten thus loosing your personalised settings (if any)
    -/etc/spam/clamav/clamd.conf and /etc/spam/clamav/freshclam.conf didn’t get overwritten thus loosing your personalised settings (if any)

    If you have manually updated spamassassin or amavisd check that:
    -/etc/mail/spamassassin/local.cf, /etc/mail/spamassassin/init.pre and /etc/amavisd.conf didn’t get overwritten thus loosing your personalised settings AND causing issues with your current versions.
    -/usr/bin/amavisd didn’t get overwritten. If it did re-install amavisd as you did the first time
    -/usr/bin/spamassassin didn’t get overwritten. If it did re-install spamassassin as you did the first time