How to fix weak DH key in Zimbra 7

I just had to fix a problem of weak DH keys in Zimbra 7. Namely, Firefox and Chrome, after upgrade, don't want to connect to servers that use DH keys less than 1024 bits. This means that IMAP won't work either, as it uses SSL/TLS too (or at least it should ;)). Note that the solution is to upgrade to newest Zimbra version, but for me at the moment there is no way I can upgrade my server, i.e. the upgrade is planned but currently it isn't possible. Googling around gave nothing for Zimbra 7, but only for Zimbra 8. In the end, it also turned out that in order to fix the length of DH keys it is necessary to have Java 8, while in Zimbra 7 Java 6 is used.

After a lot of search, the solution turned out to be easy. The key is to disable cipher suites that use DH keys. I managed to do that using the following commands:

zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_128_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_DES_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_DES_CBC3_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_EDH_RSA_WITH_3DES_EDE_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites SSL_EDH_RSA_WITH_3DES_EDE_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_DSS_WITH_AES_128_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_DSS_WITH_AES_256_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
zmmailboxdctl restart

After that, Webmail worked again. You can check supported ciphersuites using sslscan command, i.e. in my case after the given change I got the following ciphersuites:

$ sslscan webmail:443 | grep Accepted
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
    Accepted  TLSv1  128 bits  RC4-MD5

Even though Webmail worked, Thunderbird didn't connect. Using Wireshark I found out that Thunderbird, for IMAP connection, tries to use EDH-RSA-DES-CBC3-SHA. I tried to disable that ciphersuite on the server side, but no matter what I've tried, it didn't work. In the end I disabled that cipher on the client side. I opened Thunderbird's configuration editor and there I manually disabled given cipher by setting configuration setting to false.

CentOS 7, Zimbra 8.6 and FirewallD

I just installed Zimbra 8.6 on a fresh CentOS 7. It seems that CentOS 7 uses FirewallD service by default instead of the old iptables and iptables6 scripts in /etc/init.d directory. Nevertheless I don't like when I see that someone recommends some critical security services/protections to be just turned off. Those services are there for a reason, and turning them off sounds to me like the old bad recommendation of chmod'ing everything to 777 when something didn't work. Anyway, I didn't turn off SELinux and Zimbra works as expected. What I needed is to configure FirewallD to allow access to mail services from the Internet. Turns out it isn't so hard as everything is already provided. Basically, the following services have to be enabled in your zone:

• dns
• https
• imaps
• smtp

To permanently enable each of the aforementioned services, use the following command:

firewall-cmd --permanent --add-service <service>

Note that the given command doesn't activate access to the service until you restart FirewallD. Anyway, that's it.

As a final note, I didn't allow access to admin port 7171. The reason is that I'm not so comfortable with allowing Internet wide access to admin console. To access admin console, I'm going to use ssh tunneling. Basically, I'll forward local port 7171, over ssh, to port 7171 on loopback interface of mail server. In case you are unlike me, and don't have problems with allowing access to that port, use the following command:

firewall-cmd --permanent --add-port=7171/tcp

Again, don't forget to restart FirewallD after issuing the given command.

Incremental backup with rsync and cp with low disk demand

I just created very simple incremental backup solution for my Zimbra installation which efficiently uses disk space. The idea is simple. First, using rsync, I'm making a copy of existing Zimbra installation to another disk:

rsync --delete --delete-excluded -a \
        --exclude zimbra/data/amavisd/ \
        --exclude zimbra/data/clamav/ \
        --exclude zimbra/data/tmp \
        --exclude zimbra/data/mailboxd/imap-inactive-session-cache.data \
        --exclude zimbra/log \
        --exclude zimbra/zmstat \
        /opt/zimbra ${DSTDIR}/

I excluded from synchronization some directories that are not necessary for restoring Zimbra. Then, using cp I'm creating copy of this directory but which only consists of hard links to original files, the content isn't copied:

cd ${DSTDIR}
cp -al zimbra zimbra.`date +%Y%m%d%H%M`

Note the option -l that tells cp to hard link files instead of making a new copy. Also, note that the copy created is named so that it contains timestamp when it was created. Here is the content of the directory:

$ ls -l ${DSTDIR}
total 16
drwx------ 7 root   root    4096 Pro  9 15:31 zimbra
drwx------ 7 root   root    4096 Pro  9 15:31 zimbra.201412131551
drwx------ 7 root   root    4096 Pro  9 15:31 zimbra.201412140326
drwx------ 7 root   root    4096 Pro  9 15:31 zimbra.201412150325

Next time rsync runs, it will delete files that don't exist any more, and when it copies changed files it will create a new copy, and then remove the old one. Removing the old one means unlinking which in essence leaves the old version saved in the directory made by cp. This way you'll allocate space only for new and changed files, while the old ones will share disk space.

This system uses only the space it needs. Now, it is interesting to note du's command behavior in case of hard links. Here is an example:

# du -sh zimbra*
132G      zimbra
3.4G      zimbra.201412131551
3.2G      zimbra.201412140326
114M      zimbra.201412150325
# du -sh zimbra.201412131551
132G      zimbra.201412131551
# du -sh zimbra.201412150325
132G      zimbra.201412150325

In the first case it tells us how much space is used by main directory, zimbra, and then it tells us the difference in usage of the other directories, e.g. zimbra is using 132G and zimbra.201412131551 uses 3.4G more/differently. But, when we give specific directory to du command, then it tells us how much this directory is by itself, so we see that all the files in zimbra.201412131551 indeed use 132G.

And that's basically it. These two commands (rsync and cp) are placed in a script with some additional boilerplate code and everything is run from cron.

Messing up Zimbra upgrade, a.k.a. dangerous --platform-override option...

You know that Zimbra's installer has --platform-override option that enables you to install Zimbra on unsupported platforms, like CentOS. Well, it also allows you to mess up things. Namely, I downloaded Zimbra for RHEL6, but was upgrading an existing installation on CentOS5. And I didn't noticed anything unusual until upgrade process failed! It failed very early with an error message from loader that it couldn't start perl binary. Namely, the error message I got, was similar to:

/usr/bin/perl: symbol lookup error: /opt/zimbra/zimbramon/lib/i386-linux-thread-multi/auto/IO/IO.so: undefined symbol: Perl_Tstack_sp_ptr

It wasn't exactly that one, but similar! Well, I was surprised because Zimbra's upgrade process is good and robust, and I had never problems with it, but since I had some local customizations on my installation I suspected those to be the cause. So, I ended up by copying CentOS' Perl installation into Zimbra tree. This process wasn't actually so easy to do and that should've warned me that something is terribly wrong, but I continued nevertheless. But, when I managed to pass that point, the next one finally made me realize the mistake. Namely, mysql binary required Glibc 2.7, while in CentOS 5 is some earlier version. Now, I knew what mistake I've made.

Here is also a point I realised that I'm facing a long night trying to recover Zimbra installation!

So, I've downloaded the correct version of Zimbra, the one I intended to upgrade to, manually installed it using rpm tool, and then restarted upgrade process with:

/opt/zimbra/libexec/zmsetup.pl

And here my problems continued. Namely, the upgrade script correctly figured that I'm trying to upgrade, it also correctly figured the old and the new version, but it stuck on starting mysql server. After some time I managed to figure out where the problem is, namely, existing mysql database has password while the installation process assumes there isn't one. So, it couldn't determine if mysql was started or not, and everything stalled. I lost some time trying to make database not to ask for the password, and even though I managed to do something, luckily, in the mean time I stumbled on the following Wiki page:

Recovering from wrong platform upgrade

I made it large because it really got me out of the problem. It is written for version Zimbra version 5, but it works on 7, too. In a nutshell, you install the old Zimbra versions you had and then start from there with the idea of making a rollback. BUT, BIG WARNING, this is possible only if your localconfig.xml file is intact. In my case, I erased it, but the upgrade process saved a copy which I was able to recover! I had some additional problems while testing installation as suggested byt the Wiki page, but all of them were related to the tweaks I did to my installation of Zimbra, i.e. binding Zimbra to a single IP address.

What have I learned

Well, first and foremost, do a backup before doing an upgrade. Yes, I know it was stupid, and beginner's, mistake, but as I've said, Zimbra's upgrade process is really good, at least for me. The real reason I didn't do it was that it takes several hours to make it. If I had copy, I would revert to that copy, and I would only need to fix RPM database. So, to avoid the same thing happening again, now I did make a backup process which rsync'es all of Zimbra tree to an alternative location every day.

Next thing is, localconfig.xml file is extremely important, so I did additional backup of that file, too. Note that in the file are all passwords so, it's also critical from the security perspective!

Also, I would suggest that Zimbra adds checks into installation script to guard against mistakes like the one I did. It turns out, after some googling, that there are a lot more other posts with the similar problems. This can be easily done for CentOS/RHEL with appropriate requirements in RPM packages.

And for the end, here is one other story about failed Zimbra upgrade which I find interesting.

Modifying mail passing through Zimbra

I had a request to attach to (almost) each mail message that passes through the Zimbra mail server an image. Basically, what the owner wanted is that there is an image with advertisement in the mail that is sent by internal users. Additional requirements were:

1. Image should be added only once!
2. In case there is new image, and there is already on in the mail, the old one should be replaced!
3. Image has to be at exact spot within a message.

There were some additional requirements from my POV:

1. Not every mail should have image attached, e.g. automatically generated internal messages!
2. I should be careful about impact on the performance.
3. Mali messages that are not modified should not have any noticeable marks about image that isn't added (this one will be more clear later).
4. The solution should allow to define only certain senders to have mails modified.
5. It has to have a DRY RUN mode so that it is easily disabled.

I immediately knew that there is no way to place image somewhere on the Internet and put link into the mail message. Although the most elegant solution, the problem is that all mail clients don't show images by default, and that's it. So, image has to be within mail message itself. A bit of research showed up a potential solution. Namely, to embed image data within IMG tag itself, and mail messages are already altered by adding disclaimer which is HTML and a perfect place to add that IMG tag, so why not reuse disclaimer for the same purpose? In favor of that solution was also my intention not to add new scripts into the mail processing chain because of fear that it might impact performance. 

Unfortunately, that solution didn't work. The most important shortcoming is that Outlook and GMail don't handle IMG tag with embedded image data in it, in other words, the image isn't shown. To solve that, image has to be embedded as a MIME part within mail. Additionally, the other requirements aren't easy to achieve, especially, the one to replace old image with a new one. So, in the end I had to resort to writing scripts.

I already wrote about how I managed to solve more complex requirements for a disclaimer than the functionality of Zimbra allows. So, it was natural place for me to add that additional processing there. I called the script to add image altermail.py and now altermime script has the following form:

#!/bin/bash
grep "DISCLAIMER:" ${1#--input=} > /dev/null 2>&1
if [ ! "$?" = 0 ]; then
/opt/zimbra/altermime-0.3.10/bin/altermime-bin "$@"
fi
#echo "`date +%Y%m%d%H%M%S` $@" >> /tmp/altermime-args
/opt/zimbra/altermime-0.3.10/bin/altermail.py "$@" >> /tmp/altermail.log 2>&1

I'm calling altermial.py after altermime because the image placeholder is within disclaimer! Also, I removed exec keyword before altermime-bin call so that altermail.py is finished.

Additionally, note that altermail.py accepts the same arguments as altermime! This is in order to simplify things a bit.

Obviously, I choose Python as a programming language of my choice. I could write all that in Perl too, but since I'm lately working a lot more with Python, Python was the way to go. Both languages have very good support for mail processing (MIME messages in particular).

The script is on the GitHub and you can fetch it there.

How the script works

First of, script doesn't work for mail messages that aren't MIME. So, after loading a message the first check if it is a multipart message. If not, then script just exits.

Next, white and black lists are checked.

There are two passess over the mail message. In the first pass, it searches through the mail message to see if there is already image attached. If so, then it additionally checks if it is an older version of the image. If it is, it replaces the image, but in both cases it doesn't do anything more and finishes execution.

The second pass is done when there is no image in the mail message and it has to be added. Now, when adding the image it has to be added with HTML as html/related so that they are both shown. If you add it as html/alternative, then only one of them will be shown!

All the configuration options are embedded within script itself. I chose not to have configuration file to reduce number of disk accesses, which is already very high (a lot of modules are necessary).

Adding Zimbra disclaimer using shell scripts...

While Zimbra 8 (and 7, too) have domain wide disclaimer support built in, there are two shortcomings that forced me to fall back to the old way of doing it:

1. There is no support for not adding disclaimer if it already exists, and
2. No support to exclude some addresses from adding disclaimer.

The second problem I managed to solve by patching Amavis script. That approach adds extra effort for maintainability (primarily during the upgrades), but it works. To solve the first problem the same way was too much work that I wasn't prepared to invest so I had to abandon domain wide disclaimer provided by Zimbra. There was also a third problem. Namely, for all mail messages sent from Outlook, Zimbra added two extra characters at the end of a HTML disclaimer, namely characters "= A". Why is this, I don't have slightest clue. I suspect it has something to do with encoding and decoding messages while going through the mail system, but exact reasons are unknown to me.

So, I went to solve all those problems and first I tried the old way, namely modifying postfix subsystem. It turned out that it didn't work. Just for a reference, at the end of this post, I described what I did. Next, option was modifying amavis. But that turned out to be too complicated and error prone - as I said in the introduction paragraph. Finally, I decided to put a proxy script in front of altermime that will be called by amavis and that will check if there is already disclaimer. If it isn't, then it calls altermime. Note that in this way there was no need to change amavis, and that means a lot from the maintenance perspective. So, here is what I did.

First, I created the following simple script in /opt/zimbra/altermime directory:

#!/bin/bash
echo "`date +%Y%m%d%H%M%S` $@" >> /tmp/altermime-args
exec /opt/zimbra/altermime-0.3.10/bin/altermime-bin "$@"

What it does is it just logs how it was called and then it calls altermime. Note one more important thing here. In order to be able to put this script before altermime, I had to call it altermime, and altermime binary I renamed to altermime-bin. If you are doing this on a live system be very careful how you do this switch. I suggest that you first create script called altermime.sh, check that it works, and then use the following command to make a switch:

mv altermime altermime-bin && mv altermime.sh altermime

Ok, in this way I was able to find out how altermime is actually called. This is what I saw in /tmp/altermime-args file:

20130912100915 --input=/opt/zimbra/data/amavisd/tmp/amavis-20130912T100229-30384-pc8afS_K/email-repl.txt --verbose --disclaimer=/opt/zimbra/data/altermime/global-default.txt --disclaimer-html=/opt/zimbra/data/altermime/global-default.html

That's just one line of the output. As it can be seen, the first argument specifies file with mail message, and the rest specify disclaimer to be added. So, in order not to add disclaimer, if there is already one, I modified the altermime.sh script to have the following content:

#!/bin/bash
grep "DISCLAIMER:" ${1#--input=} > /dev/null 2>&1
if [ ! "$?" = 0 ]; then
    exec /opt/zimbra/altermime-0.3.10/bin/altermime-bin "$@"
fi

Again, be careful if you are modifying this script on a live system.

Now, in order to control where disclaimer is added, you can modify this simple shell script. One more thing you should be aware of, this approach impacts performance as, instead of running one process, it now runs at least 3 per mail message, and there are few extra file accesses. 

Finally, as a side note, I managed to get rid of those strange characters added to Outlook's email messages. I just edited a little bit html file that contains disclaimer, and those characters were gone. That's definitely a bug somewhere, but who knows where...

The old way that didn't work

As I said, the first approach I tried is to use the procedure from Wiki. But it didn't work. Anyway, for a reference, here is what I tried to do. Note that, as Zimbra already ships with altermime, there is no need to install it. The altermime is in /opt/zimbra/altermime/bin directory and you can safely use it. Ok, now to changes:

First, change a line in master.cf.in that reads

smtp    inet  n       -       n       -       -       smtpd

into

smtp    inet  n       -       n       -       -       smtpd        -o content_filter=dfilt:

and also add the following two lines:

dfilt   unix  -       n       n       -       -       pipe
        flags=Rq user=filter argv=/opt/zimbra/postfix/conf/disclaimer.sh -f ${sender} -- ${recipient}

Note that by this last line you specified that your script is called disclaimer.sh and that it is placed in /opt/zimbra/postfix/conf directory. This script, when run, should be run with a user privileges filter. Also, be careful where you put those lines. Namely, put them after the following three lines:

%%uncomment SERVICE:opendkim%%  -o content_filter=scan:[%%zimbraLocalBindAddress%%]:10030
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_filter=[%%zimbraLocalBindAddress%%]:10027
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_options=speed_adjust

The reason is that those line logically belong to the first smtp line, and if you add dfilt in front of it, you'll mess things, probably very badly, depending on your luck!

If you had Zimbra's domain wide disclaimer enabled, then disable it using:

zmprov mcf zimbraDomainMandatoryMailSignatureEnabled FALSE

as a zimbra user, and then restart amavis:

zmamavisdctl restart

still as a zimbra user.

Finally, to active custom script to add disclaimer run the following command as zimbra user:

zmmtactl restart

After I did all that, it didn't work. :D But, then I realized that there are two content_filter options to smtp which might not work, and so I resorted to proxying altermime.

Zimlets for managing posix & samba attributes...

Well, this isn't actually new news, but nevertheless I managed to avoid it for some time now. Namely, Zimbra, with upgrade to 7.2, removed plugins that are used to manage Samba and Posix accounts in its LDAP directory. Now, whenever someone asked what about this Zimlets, the answer was "This was never supported by Zimbra and thus someone from community has to step in." If you Google a bit, you'll easily find it, e.g. here or here. Now, this probably is a perfectly reasonable answer from the Zimbra's standpoint, but I believe that Zimbra should know that this plugin was more frequently used one (let me guess it: because it's useful?) and they have to listen their users.

But whatever is/was with those plugins, I had to have them because one of my setups is such that it contains all account databases in Zimbra. When I disabled Samba and Posix Zimlets, everything worked as usual, apart that I was unable to add new users via Web interface. After I managed to get with it for some time now, the time has come that I had to add another user account and I had to see what I'm going to do with non-working Web interface.

After some googling I discovered that someone managed to fix those two plugins, and also at the time this post was written, there are no news if those plugins work with version 8. So, in short, don't upgrade yet if you are using those plugins. To see what was changed in the plugins to make them work, take a look at this post. In any case, go to the Zimbra's gallery and download Posix and Samba Zimlets. The versions I used are 28.5.12 - v6.1 for both Zimlets. Now, before installing open the archives and in each one you'll find config_template.xml files. Open those files in text editor and fill in the correct values. The most important one is LDAP suffix which is by default set to dc=domain,dc=tld and which you should change to reflect your domain. For example, if your domain is example.com then the suffix will be dc=example,dc=com. After you've made changes, save files and put them back in the archive. If you don't do that you'll receive error reports when logging in admin console, and also there will be no existing samba and possix groups. Not to mention that you'll be unable to create new accounts.

Ok, the last step is to undeploy the old versions - in the case you didn't already, and deploy new ones. After deploying, you should log out and then back in and you should see their options under the Configuration section (in the left pane). If you click on, e.g. Manage Samba Groups, you'll see your existing Samba groups. Similarly has to be with the option Posix Groups. If there are no groups (and you know there should be) than you probably messed with LDAP suffixes I was talking about.

And that's it. For the end, if someone from Zimbra is reading this post, then I have a message for you. Namely, don't answer to so many people that you don't support something because it was always unsupported. I don't think it's relevant. If people are using it, and they find it useful, then you should support it. Or at least devote one engineer day to fix the problem. It isn't so expensive and people will have much better opinion about Zimbra.

Zimbra log cluttering...

When you run Zimbra, logs generated by it are duplicated in system log files (i.e. /var/log/messages, or /var/log/secure) but also in Zimbra specific log files (i.e. /var/log/zimbra.log). The problem with this is that it clutters system logfiles, i.e. takes unnecessary space and makes them hard to analyze. So, it would be good to make Zimbra log only in its own specific log files.

Googling for solution I found this post but with no satisfactory solution. Since there was no ready solution, I turned to Googling on how to configure rsyslog to do that. Namely, CentOS (on which I'm running Zimbra) uses rsyslog as a replacement for a more traditional syslog. It turns out it is possible to filter according to application doing logging.

So, two offending applications are zimbramon and zmmailboxdmgr. In order to prevent them from logging into /var/log/messages add the following lines before section RULES (that resemble classical syslog rules):

if $programname == 'zimbramon' then /var/log/zimbra-stats.log
& ~

if $programname == 'zmmailboxdmgr' then /var/log/zimbra-stats.log
& ~

The first two lines will redirect zimbramon messages, while the second two will do the same for zmmailboxdmgr.

Zimbra 7 and domain wide disclaimer...

In Zimbra 7 it is not necessary any more to hack scripts in order to get domain wide disclaimer. At least not if you want to add the same disclaimer to every mail that passes through your mail server. In case you want more control, like not attaching it to some mails, then you'll have to resort again to scripts and hacking.

So, to add disclaimer, the following would do:

zmprov mcf zimbraDomainMandatoryMailSignatureText <text disclaimer>
zmprov mcf zimbraDomainMandatoryMailSignatureHTML <html disclaimer>
zmprov mcf zimbraDomainMandatoryMailSignatureEnabled TRUE

and finally, reload amavis configuration using

zmamavisdctl reload

Note that whenever you change any of the previous three attributes you have to restart amavis. Those attributes are accessed only when amavis is started and they are used as an input to configuration writing routines.

You can query current values using gcf instead of mcf (don't forget to leave out last arguments because you are not setting values!).

Well, now, there were some problems.

The first one is that you disclaimer has probably more that one line, anyway more that you are prepared to type. In that case you can put it into a file and then use backtick shell notation with cat command to place the content of a file into appropriate place. Don't forget to place double quotes around everything so that spaces are not interpreted by the shell (like this "`cat somefile`")! There are other methods too, but this hack worked for me. Well, almost, becuse when text version of a disclaimer was attached to the text only mail, everything after the first line was cut off. HTML on the other hand worked, but, it also suffered from the second problem. And the second problem is...

The second problem is that I have Croatian in disclaimer which means it's encoded using UTF-8, and that, for some reason, doesn't play well with the LDAP, or some command inbetween, that transfers text/html disclaimer into LDAP. But I noticed that other tools, e.g. vi/vim, even bash, behaved strangely upon encountering some Croatian character. Trying to set environment variable LANG to en_US.utf8 before executing zmprov command didn't work either! And the command locale showed that C was still used. I managed to fix this by commenting out the following two lines in ~zimbra/.bash_profile file:

#export LANG=C
#export LC_ALL=C

After that (don't forget to login/logout) bash and vi started to work as expected but Zimbra still was messing up the disclaimer. That is, until I restarted amavis again. Then, it worked. In case it still doesn't work, set HTML attribute using zmprov command and restart amavis again!

This locale setting is nothing new in Zimbra. I checked previous version of Zimbra and it was also there. But until now I never had to put UTF8 into LDAP and so I never had hit this particular error.

This has left me with the last problem, text attachment isn't working as it should. So, I opened amavis configuration file /opt/zimbra/conf/amavisd.conf to see what's exactly going on. In there, I found that the file with the disclaimer should be in /opt/zimbra/data/altermime directory and it should be named _OPTION_.txt. Well, it is there but not called _OPTION_.txt. It could be that some postprocessing is performed on the values in amavis configuration file, but I ignored that as it is not important. What is important is that the file with disclaimer is called global-default.txt and it had wrong content, i.e. only the first line of the disclaimer. For a quick test I replaced it with the disclaimer I wanted to have, and voila, it worked!!!

So, why is there an error? I'll investigate later since now I have to do other things. :)

More fun with ssh tunnels... accessing Web

Suppose that you have some Web application and you can access it only from local network, either because firewall on the host itself protects access or there is firewall at the network perimeter. Either way, you are currently somewhere on the Internet and you have to access this application, e.g. some administrative interface.

In my case, I have Zimbra Web administrative console access confined to local network only and sometimes it happens that I have to access it from remote location. Suppose that the remote site is zimbra.domain.com and that Zimbra Web administration interface is at default port 7071. I'll use z.z.z.z to denote IP address of that server. Additionally, you need to have some server within your local network that allows SSH access. This server has to be visible from the Internet, and if it is directly accessible that everything is fine. Otherwise, if you are using NAT you'll have to punch a hole in your firewall to forward all the connections from the outside to that machine. Either way, suppose that this server has public IP address s.s.s.s.

Ok, here is what you have to do. From your local machine, i.e. the one that you are currently work on and that is outside of you local network, execute the following ssh command:

ssh -L 7071:z.z.z.z:7071 s.s.s.s

All you have to do now is to open Web brower and enter the following URL:

https://127.0.0.1:7071

In case when virtual hosts are used, you'll have to add the following line into your /etc/hosts file:

127.0.0.1           web.server.name

and then, URL you'll use is:

https://web.server.name:7071

While this is necessary in general case, in case of Zimbra it is not since Zimbra should be only service running on a particular IP address.