postfix error with inbounds mails

Excuse my english I’m spanish speaker.

I have a Debian 4 server:

That server have the default Virtualmin install.

I need to fix a postfix error:

Inbounds mails do not come to the users mailbox. I see it in the mail spool but the mail never comes to the users accounts. The weird thing is that the server never returns a error message to the sender.

Any help please !!

Thanks in advance.


srv1:/etc/postfix# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
home_mailbox = Maildir/
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mydestination = $myhostname, localhost.$mydomain, $mydomain
mynetworks =
myorigin = /etc/mailname
recipient_delimiter = +
sender_bcc_maps = hash:/etc/postfix/bcc
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destinationsmtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = hash:/etc/postfix/virtual

Hi Roberto,

A few questions for you –

First, do any emails get delivered to any account? Or are all emails to all users not being delivered?

Second, do you see any errors in /var/log/mail.log when trying to send a message?

If the messages are sitting in the mail spool, Postfix may be logging an error into the error log.

Thanks Eric for your reply

>First, do any emails get delivered to any account? Or are all emails to all >users not being delivered?

All mail, all domains. Looks a external virtualmin error but I cannot find it.

>Second, do you see any errors in /var/log/mail.log when trying to send a message?
>If the messages are sitting in the mail spool, Postfix may be logging an error >into the error log.

Now I send a mail for my gmail account, I see the mail in the mail log and spool but it never comes to the user account.
After some minutes in the spool, the mail disappears without any error message to the sender.

srv1:~# tail -f /var/log/mail.log

Nov 6 04:21:58 srv1 postfix/smtpd[3674]: connect from[]
Nov 6 04:21:58 srv1 postfix/smtpd[3674]: CF49110600C4:[]
Nov 6 04:21:59 srv1 postfix/cleanup[3679]: CF49110600C4: message-id=<>
Nov 6 04:21:59 srv1 postfix/qmgr[9398]: CF49110600C4: from=<>, size=2042, nrcpt=1 (queue active)
Nov 6 04:22:29 srv1 postfix/smtpd[3674]: disconnect from[]

Hrm, you don’t by chance see anything in /var/log/procmail, do you?

Thanks a lot for your help !

This is my procmail.log output when I send a mail to the test domain:

srv1:/var/log# tail -f procmail.log

Time:1226053488 Size:2164 Dest:/dev/null Mode:Virus

Looks that procmail is sending all mails to /dev/null …

This mail do not have any virus, is a only test mail form gmail (tested with gmail).

I just have disabed the antivirus support in "System Settings" — "Features and plugins" — "Virus filtering".

Any hint ?


Well, that particular email that you mentioned was tagged as a virus, yeah.

Are you now able to send yourself emails though?

Hi !

Whe I send a mail from to

tail -f /var/log/procmail.log

From Fri Nov 7 10:34:43 2008
Subject: test
Folder: /usr/sbin/sendmail -oi 743
Time:1226062243 Size:799 Mode:Virus
procmail: Timeout, terminating "/etc/webmin/virtual-server/"
procmail: Program failure (-15) of "/etc/webmin/virtual-server/"

I have other new fresh server instaled and have the same issue. Maybe a virtuamin/debian/clamav bug ?


I the last post I had configured virtualmin to send all virus mails to my gmail account but that not works.

Your clamscan is taking too long to return. But, this shouldn’t result in /dev/null on any new version of Virtualmin (the result from a timeout from the AV test should be delivery in recent versions). I’ve asked Jamie to have a look at this thread, as this would be a bug, if timeouts are still resulting in delivery to /dev/null.

But, to resolve your problem immediately…switch to clamdscan. It’s much faster, and so won’t time out like this.

The latest version of Virtualmin imposes it’s own timeout on clamscan to avoid this problem of it being killed by procmail, but that could fail if the system is so loaded that Virtualmin’s never gets a chance to even start.

The simple fix is to edit /etc/procmailrc and add the following line at the top :


The better fix is to run clamd as Joe suggested, which can process email with far less CPU load.

Thanks for your help !!

I confirm that I running the latest virtualmin version (3.63.gpl (GPL)) with debian etch (default script install)

I am going to try the advices that gave me.



Just want to let you know that I have the same problem on a similar configuration.

Operating system Debian Linux 4.0 Webmin version 1.441 Virtualmin version 3.63.gpl (GPL)

sd-13867:~# tail -f /var/log/procmail.log

From Wed Dec 3 17:46:04 2008
Subject: Test #3
Folder: /dev/null 3359
Time:1228323724 To:«» User:fftarot-main Size:3359 Dest:/dev/null Mode:Virus
procmail: Timeout, terminating "/etc/webmin/virtual-server/"
procmail: Program failure (-15) of "/etc/webmin/virtual-server/"

sd-13867:~# tail -f /var/log/mail.log

Dec 3 18:04:09 sd-13867 postfix/local[1124]: 6A01D2A40B8: to=<>, orig_to=<>, relay=local, delay=3068, delays=0.06/2107/0/961, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME)
Dec 3 18:04:09 sd-13867 postfix/qmgr[2834]: 6A01D2A40B8: removed

I will also try the fix.



I solved it uninstalling clamav. Looks a virtuamin/clamav/debian bug.

Now all works fine.


Hi roberto,

Yes, indeed, I think it’s a bug. My server was just installed and was not overloaded … the problem occurs even if the cpu is idle.

I am not sure that uninstalling clamav is the best option for a webserver. It could be a great idea for us to fill a bug report. DO you use the 32bits or 64bits edition of Debian ?


Hi Tristan

I’m using the 64 bits debian edition.

You have right, uninstalling clamav is not the best option for a webserver. I have installed ASSP ( in the same server to replace spamassasain/clamav.


One thing to try is running clamd, which responds much faster than clamscan - particularly on Debian, where the stock clamscan package is terribly slow.

There is documentation at on this…

I got it !!! In my case, at least, the problem was with clamav : I did a ‘top’ and I saw that a lot of processes of clamd where stuck and used all cpu ressource.

The clamav log file gave me a clue : “ERROR: Can’t lock database directory: /var/lib/clamav/” Each clamd process failed with this error and stayed alive, using more and more cpu.

After googling, I find a topic related to this problem :

After uninstalling the installed version of clamav (0.90.1dfsg-4etch15), I then followed the instructions of mr88talent on Sat Oct 13, 2007 11:47 am that installed the new version (0.94.dfsg.1-1~volatile1) and everything works fine now.


What is debian-volatile?

Some packages aim at fast moving targets, such as spam filtering and virus scanning, and even when using updated data patterns, they do not really work for the full time of a stable release. The main goal of volatile is allowing system administrators to update their systems in a nice, consistent way, without getting the drawbacks of using unstable, even without getting the drawbacks for the selected packages. So debian-volatile will only contain changes to stable programs that are necessary to keep them functional.

Yes, using the volatile repo is a very good idea - it’s version of clamav is both more reliable and catches more viruses than the one in the standard debian repo.