Too much deferred messages in Zimbra?

Having too much deffered messages in Zimbra Collaboration Suite? And this error usually happened when messages with big attachment is sent?

Error example:

[root@mail ~]#  grep deferred /var/log/maillog
Apr 10 05:32:09 mail2 postfix/smtp[5543]: 2EEF859C06A: to=<nurhidayaharipin_87@yahoo.com.my>, relay=mx1.mail.sg1.yahoo.com[124.108.116.109]:25, delay=217976, delays=217793/0.02/0.4/183, dsn=4.4.2, status=deferred (conversation with mx1.mail.sg1.yahoo.com[124.108.116.109] timed out while sending message body)

The error is related to Postfix, one of the main Zimbra component. This is due to a message take too much time when sent to a recipient. Exceeding the timeout limit defined in the server. To solve the situation, we can increase the timeout limit.

To do this, edit a Postfix configuration file, main.cf.

sudo vim /opt/zimbra/postfix/conf/main.cf

.. and append these lines to the file. By default, Zimbra man.cf does not have  these lines like in other Postfix mail server configuration.

smtp_data_done_timeout = 600s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 600s

The effective attributes should be smtp_data_xfer_timeout. The bigger the values, the better. But for me 600 should be enough. Restart the service to implement the new configuration. That should do the work.

Source:

http://serverfault.com/questions/55949/postfix-timed-out-while-sending-message-body-to-microsoft-esmtp-mail-service

http://forums.fedoraforum.org/showthread.php?t=68888

Squirrel Mail ~ Change Password Plugins Fails

While working with squirrelmail in UMK mailserver, I encountered one strange problem. When I installed the change_password plugin, it failed to operate. A user cannot change his password even though the current password he entered is correct. Even worse, when i disable $confirmNewPass and $confirmOldPass in the config.php file, the same error keep hunting my users.

Although the plugin worked when run in bash shell but not from the website. Quite an interesting situation.

Further investigation shows that there is something wrong when the script is run from the website. SELinux is preventing the plugin from being run correctedly. The output of dmesg is like this:

audit(1184206216.485:2): avc: denied { execute } for pid=3140 comm=”chpasswd” name=”ld.so.cache” dev=hda4 ino=457427 scontext=user_u:system_r:httpd_sys_script_t tcontext=root:object_r:ld_so_cache_t tclass=file

audit(1184206216.486:3): avc: denied { setuid } for pid=3140 comm=”chpasswd” capability=7 scontext=user_u:system_r:httpd_sys_script_t tcontext=user_u:system_r:httpd_sys_script_t tclass=capability

audit(1184206228.873:4): avc: denied { execute } for pid=3142 comm=”chpasswd” name=”ld.so.cache” dev=hda4 ino=457427 scontext=user_u:system_r:httpd_sys_script_t tcontext=root:object_r:ld_so_cache_t tclass=file

audit(1184206228.874:5): avc: denied { setuid } for pid=3142 comm=”chpasswd” capability=7 scontext=user_u:system_r:httpd_sys_script_t tcontext=user_u:system_r:httpd_sys_script_t tclass=capability

Firstly, I am not sure what is going on but there is some security prevention involved. Later after I did some googling I realized that SELinux is the cause of the problem. This is the SELinux status on the machine:

[root@mail ~]# getenforce
Enforcing

[root@mail change_passwd]# getsebool -a
allow_syslog_to_console –> inactive
allow_ypbind –> inactive
dhcpd_disable_trans –> inactive
httpd_builtin_scripting –> active
httpd_disable_trans –> inactive
httpd_enable_cgi –> active
httpd_enable_homedirs –> active
httpd_ssi_exec –> active
httpd_tty_comm –> inactive
httpd_unified –> active
mysqld_disable_trans –> inactive
named_disable_trans –> inactive
named_write_master_zones –> inactive
nscd_disable_trans –> inactive
ntpd_disable_trans –> inactive
pegasus_disable_trans –> inactive
portmap_disable_trans –> inactive
postgresql_disable_trans –> inactive
snmpd_disable_trans –> inactive
squid_disable_trans –> inactive
syslogd_disable_trans –> inactive
use_nfs_home_dirs –> inactive
use_samba_home_dirs –> inactive
use_syslogng –> inactive
winbind_disable_trans –> inactive
ypbind_disable_trans –> inactive

Now I have to disabled the appropriate SELinux boolean. but… which is the correct one? hmm…. Well i think it is better to just disable the SELinux first and figure out the boolean later.

I disabled the SELinux using this command

[root@mail change_passwd]# setenforce 0
[root@mail change_passwd]# getenforce
Permissive

And wow… the new plugin run smoothly after that.