[Mailman-Users] Posts To List Not Working: But Admin Emails Do

Karl R. Balsmeier karl at sfdata.net
Tue Apr 27 20:23:35 CEST 2004

Problem was solved as I described, the "log" was created using exim's 
debugger.  You start exim with -d9 -bd, and then you submit a post to a 
list, the Exim debugger "catches" the traffic in real time, and tells you 
in a deeply verbose way what it's doing to deliver the message to the 
list.  It showed about 241 lines down the session starting to error out, a 
nice, verbose error, complete with quasi-solution in quotes.

This is nifty for all sorts of inbound/outbound checks, often telling you 
exactly what you need to do.

The "log" I speak of was simply the transcript of the exim debug level 9 
session.  I made it with my putty client and reviewed it with my boss.  We 
found a broken pipe at line 241, and sure enough, the exim "director" was 
puking on "guest" when it needed "daemon".

Exim uses "directors" and "transports" as mechanisms for getting 
list-related emails to their proper destination.

Many people have googled this error and try to recompile their ports to use 
--with-mail-gid.  I didn't have to do this because the debugger proved you 
can get some precise information, much more than the normal static logs for 
exim (mainlog/rejectlog), and for mailman, because it's so much more 
verbose at d9.

Thanks for showing me where to find the logs in Mailman, these complete the 
picture in stellar fashion, my lists are up and running now, and I noticed 
right away posts sent from squirrelmail-webmail sessions do not 
work.  Squirrelmail is IMAP-based, so i'm assuming the 'post' log will 
contain some errors I can sift a solution for.

My postings from Eudora and Ximian, both of which are using pop3d, work 
great.  Any idea what could be causing this?

Anyhow, much thanks for the info thus far!


At 10:25 AM 4/27/2004 +0100, Richard Barrett wrote:

>On 27 Apr 2004, at 09:50, Karl R. Balsmeier wrote:
>>We found it was a group_id problem in /etc/exim/configure.
>>The following block of code was corrected to read:
>>   driver = aliasfile
>>   file = /etc/mail/aliases
>>   search_type = lsearch
>>   user = daemon
>>   group = daemon
>>   file_transport = address_file
>>   pipe_transport = address_pipe
>>Where group=daemon, it used to say "guest".
>>The log file was what caught this.
>Which log file?
>>   I opened a console and typed:
>>./usr/local/sbin/exim -d9 -bd
>>The error in the log
>Which log?
>>looked like this:
>>Mailman mail-wrapper: Group mismatch error.  Mailman expected the mail 
>>wrapper script to be executed as group "daemon", but the system's mail 
>>server executed the mail script as group "guest".  Try tweaking the mail 
>>server to run the script as group "daemon", or re-run configure,
>>providing the command line option `--with-mail-gid=guest'.
>>My question about mailman logs is still open in curiosity, -are here 
>>actual logs, or justmethods to check out what's going on?
>Maybe I have not understood your question but here goes. Mailman writes a 
>number of logs to its log directory, see below the directory listing from 
>my system. The log file names are fairly explanatory. Normally, the most 
>useful tend to be the error, post, smtp and smtp-failure logs:
>user at server:$prefix/logs> ls -1 | grep -v "\."
>There will not be much in these logs and the log files may not have even 
>been created if the MTA was failing to deliver to Mailman, as seems to be 
>your case. Without the stimulus of incoming mail the logs may have yet to 
>be opened/created for the first time.
>>At 09:43 AM 4/27/2004 +0100, Richard Barrett wrote:
>>>On 27 Apr 2004, at 07:50, Karl R. Balsmeier wrote:
>>>>Creation and subscription to lists works great, email is making it from
>>>>the mailman host to the mail server, but when I post to a list, (i have
>>>>test users who have joined the list, etc.), nothing comes through?
>>>Have you started $prefix/bin/mailmanctl (MM version 2.1.x) or installed 
>>>the MM crontab (MM version 2.0.x)?
>>>>Where are the mailman logs?  I'll check em out'...
>>>$prefix/logs/ is a good place to look; and also check the MTA's mail log 
>>>to check it is delivering to MM successfully
>>>Are messages accumulating in any of the subdirectories of $prefix/qfiles/ ?
>>>Take a look a some of the MM FAQ entries (see the link in the std footer 
>>>of mail from the mailman-users list)

More information about the Mailman-Users mailing list