owner-postfix-us...@postfix.org wrote on 08/04/2011 03:14:43 PM: > From: > > Noel Jones <njo...@megan.vbhcs.org> > > To: > > postfix-users@postfix.org > > Date: > > 08/04/2011 03:15 PM > > Subject: > > Re: Postfix mail transport unavailable > > Sent by: > > owner-postfix-us...@postfix.org > > On 8/4/2011 2:39 PM, Geoffrey R Hardin wrote: > > We are running Postfix on a SuSE 11 SP 1 host, using ClamAV and > > ClamSMTP to scan mail messages. Mail delivery and reception works > > great. Had some issues with duplicate mail messages that we fixed > > with a global procmailrc file. The one remaining problem we have is > > that when we send mail to a relatively large mail alias (441 > > addresses), the system will process through 284 addresses and flag > > the message as unsent and put it back in the queue with the error > > message "mail transport unavailable". Unfortunately, the system is > > on a separate network so I can't easily post configuration files, > > but if someone knows where I could start looking, I can post > > specific configuration items. > > > > For example, I have tried increasing the number of open files in the > > /etc/security/limits.conf (up to 32k), I have increased several > > values in the /etc/clamd.conf file to see if I was running into some > > resource limitation (increased MaxThreads, StreamMaxLength, and > > MaxQueue); I have done the same for clamsmtpd.conf (increased > > MaxConnections to 1023; it wouldn't let me set it to 1024). Within > > master.cf I have set the post-processing smtpd service option > > smtpd_client_connection_count_limit and > > smtpd_client_connection_rate_limit to 0 to disable them. It seems to > > me that somewhere I am running into a resource limit, but I can not > > find any trace of what or where. > > > > Thanks, > > > > Geoff > > > > > Start here: > http://www.postfix.org/DEBUG_README.html > pay particular attention to: > http://www.postfix.org/DEBUG_README.html#logging > > > If you need more help, we need detailed information of the > configuration and standard (NOT verbose) logging. Without such > information we're just guessing. My first guess is that this isn't > a resource problem and the logs have more detail in a different message. > http://www.postfix.org/DEBUG_README.html#mail > > > > -- Noel Jones
Again, since this mail server is on a separate network, I am unable to post the contents of postconf -n. I understand that without that information, a lot of this is just guess work, but I appreciate the guesses so that I can start looking in the right places. I enabled verbose logging on the smtpd process and now I was able to see the following messages: postfix/local[29012]: 601C37157: to=<user284@domain>, relay=local, delay=17006, delays=16998/0/0/8.3, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail) postfix/qmgr[28990]: warning: private/local socket: malformed response postfix/qmgr[28990]: warning: transport local failure -- see a previous warning/fatal/panic logfile record for the problem description postfix/qmgr[28990]: warning: connect to transport retry: Connection refused postfix/master[18505]: warning: process /usr/lib/postfix/local pid 29012 killed by signal 11 postfix/qmgr[28990]: 601C37157: to=<all@domain>, relay=none, delay=17007, delays=16998/9.2/0/0, dsn=4.3.0, status=deferred (mail transport unavailable) After this, I enabled verbose logging on the local process and I watched the attempted delivery of the mail message again. This time, I could see the mail being processed for each recipient: <...snip...> postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: 601C37157: to=<user283@domain>, relay=local, delay=17006, delays=16998/0/0/8.3, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail) postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: 601C37157: to=<user284@domain>, relay=local, delay=17006, delays=16998/0/0/8.3, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail) postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 postfix/local[20199]: path: active/601C37157 postfix/local[20199]: queue_id: 601C37157 <...snip...> postfix/qmgr[20138]: 601C37157: to=<all@domain>, relay=none, delay=7475, delays=7461/14/0/0, dsn=4.3.0, status=deferred (mail transport unavailable) As you can see, it processes up to user284@domain and then it seems to hit a wall and stop processing the mail message for the remaining users. Because this seems to be complaining about local and/or transport, I took a look for anything related to those in the postconf -n output. local_header_rewrite_clients = permit_mynetworks transport_maps = hash:/etc/postfix/transport The /etc/postfix/transport file is very simple: domain : .domain : # # someone insists on sending to a FQDN instead of just the domain name, # but the host is not a mailserver, so we'll force mail to go the the mail server host.remote.domain smtp:[ad.dd.re.ss] # # These are fake domains that DNS does not know about, so we'll forward # the mail to their mail server other.domain smtp:[o.th.e.r] .other.domain smtp:[o.th.e.r] Is there something with the socket that the local process is using? Is there an error with the transport map? Thanks again, Geoff
