Doug Jaquays wrote: > > Hello, > > > We recently moved our anti-virus server to Linux, eTrust ITM and > SLES10sp1 with all available updates without going to sp2. When our > clients have notifications that match our policy, they are forwarded > to the server, which then sends the notification to a php script that > parses the information and emails it using the mail() command. > Everything appears to work as intended to this point. The problem is > that once the mail gets in queue, it seems to almost never be picked > up until some form of human interaction wakes up > master/pickup/qmgr/whichever-piece-it-is-that's-not-working. The > human interaction part seems to be flakey as well. Sometimes flushing > the queue works immediately, sometimes it doesn't. I had a message > sit in the queue for almost 24 hours and when I tried to run strace on > master as some website suggested, it suddenly sent the message > through. It does appear to somehow be related to how long it sits > idle without sending a message. eTrust screwed up one of their > definition releases that tagged javascripts inappropriately about a > week ago and it was sending messages very frequently which all made it > through. I've searched all of what I would believe to be the obvious > causes of my problem and for any errors that explain the issue. I'm > sure I'll be asked, so here are the potentially relevant pieces of > data: /_http://pastebin.com/m6bc0ebe8_/ > >
I hope you have more in your master.cf than listed in that pastebin. It is severely lacking some entries. Logs for a transaction entering to delivery would help as well. > postconf -n: > alias_maps = hash:/etc/aliases > defer_transports = That's good. Postfix will not hold things on purpose > smtpd_sender_restrictions = hash:/etc/postfix/access Depreciated, suggested to use 'check_sender_access hash:/etc/postfix/access' to avoid future confusion/breakage. > transport_maps = hash:/etc/postfix/transport What is in here? Brian
