| |||||||||||||||||||||||||||||||
|
appearently our external mailhub ran out of memory this night, because clamav needed to much memory. That caused a lot of mails to be not delivered to our internal mail server and instead beeing queued on the mailhub. Now I removed the content scan mechanism (cause I cannot currently restart the system to add RAM) and tried to flush the queue, but it results in messages like the follow immediately (so I think it does not even try to really flush!): Nov 15 10:04:58 imr-ext postfix/qmgr[28957]: F2BA3C00A13: to=<info>, relay=none, delay=58974, delays=5 8974/0.03/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]: Connection refused) I don't know If I am right, but I am aware that a lot of mailservers implement something thats like a 'hard freeze' when mail submission results in a lot of errors in a short time. That means that the mailserver won't try to deliver within a certain time for those mails. I don't know if postfix has such a logic, but if i would think that is whats happening here. But how can I force postfix to process these mails? How can I postfix force to process frozen mails at all? (because something like sendmail -qf is not supported). I feel quiet confident in this because new mail processing seems to work. I tried to fastflush mails for some important domains with -qRdomain but that does not work either. What am I missing? How can I debug this, because adding -v to the qmgr process in master.cf does not produce useful output. How can I be sure what postfix is trying to connect? (Because it only says it cannot reach 127.0.0.1 but not a port or something). Thanks in advance Best Regards Patrick
| ||||||||||||||||||||||||||||||
© 2004-2008 readlist.com