[Mailman-Users] messages aren't being delivered to users, but are in the archive

[jacob walcik]

bizarre.  changing the SMTPHOST in mm_cfg.py from 'localhost' to the  
hostname of the server fixed it.

thanks for all the help!

On Wednesday, Jun 25, 2003, at 10:56 US/Central, Richard Barrett wrote:

> At 16:39 25/06/2003, jacob walcik wrote:
>> alright, upgraded to 2.1.2 as per the recommendation in the original  
>> response.  same problem continues, but now i've actually got error  
>> messages from the logs to share.
>>
>> from logs/smtp:
>> Jun 25 10:23:12 2003 (11504) All recipients refused: (111,  
>> 'Connection refused')
>> Jun 25 10:23:12 2003 (11504) All recipients refused: please run  
>> connect() first
>> Jun 25 10:23:12 2003 (11504)  
>> <A67DFAFA-A721-11D7-9444-000393914A3A at mail.utexas.edu> smtp for 2  
>> recips, completed in 0.037 seconds
>>
>> from Defaults.py (not overridden in mm_cfg.py):
>> SMTPHOST = 'localhost'
>> and
>> DELIVERY_MODULE = 'SMTPDirect'
>>
>> where is the "All recipients refused" message coming from?  postfix's  
>> log shows the message going through just fine:
>> Jun 25 10:23:12 dastardly postfix/local[11553]: B03606000E:  
>> to=<test at mail.laits.utexas.edu>, relay=local, delay=1, status=sent  
>> ("|/usr/local/mailman/mail/mailman post test")
>
> This mail log entry apparently shows the delivery of the incoming  
> message to Mailman.
>
> The MM post log entry seems to be saying that MM could not make a  
> connection in order to send _out_ a message to the list's subscribers.  
> There may also be a message in the MM smtp-failure log.
>
> You can find out what MM is trying to use for outbound message  
> transport by looking in $prefix/Mailman/Defaults.py unless you have  
> overridden these by assignments in $prefix/Mailman/mm_cfg.py. Usual  
> defaults are:
>
> DELIVERY_MODULE = 'SMTPDirect'
>
> SMTPHOST = 'localhost'
>
> The error reported seems to indicate that Mailman is having trouble  
> connecting to whatever outgoing mail server it is trying to  
> communicate with..
>
>
>> On Tuesday, Jun 24, 2003, at 17:19 US/Central, Richard Barrett wrote:
>>
>>> At 22:08 24/06/2003, jacob walcik wrote:
>>>> yup, the mailman user's crontab was installed as part of the rpm
>>>> installation, and i've also tried running qrunner manually w/ the
>>>> command it's issuing, and i don't receive any errors.
>>>>
>>>> assuming mailman's home is /var/mailman, where would i look for the
>>>> "qfiles" file.  a "find ./ -name "qfiles" -print" from /var/mailman
>>>> doesn't return anything.
>>>
>>> Given your install in /var/mailman and a normal MM 2.0.x install  
>>> there should be a directory called /var/mailman/qfiles. The script  
>>> in /var/mailman/scripts takes delivery of incoming messages from the  
>>> MTA creates a .msg and a .db file in that directory. The qrunner  
>>> subsequently takes those files and processes them, sending mail out  
>>> etc.
>>>
>>> The actual qfiles directory used for enqueueing incoming messages is  
>>> defined by the config variable QUEUE_DIR in  
>>> $prefx/Mailman/Defaults.py or possibly (and unusually) overridden  
>>> $prefix/Mailman/mm_cfg.py. If that directory doesn't exist then  
>>> something in your install may be screwed.
>>>
>>> But looking again at your original post you say the message is  
>>> getting into the archives. That says the message is passing through  
>>> qfiles, being picked up by the qrunner and so you would expect there  
>>> to be some trace of its progress in one of Mailman's log files.
>>>
>>> But you say the directory says $prefix/logs doesn't exist. The log  
>>> file directory is defined by the config variable LOG_DIR in  
>>> $prefix/Mailman/Defaults.py or possibly (and unusually) overridden  
>>> $prefix/Mailman/mm_cfg.py. If that directory doesn't exist then  
>>> something in your install may be screwed.
>>>
>>> What value does the config variable DELIVERY_MODULE in  
>>> $prefix/Mailman/Defaults.py or possibly overridden  
>>> $prefix/Mailman/mm_cfg.py have and also SMTPHOST.
>>>
>>> Are there are no logs and no sign of what is happening exists in  
>>> MM's error, post, smtp and smtp-failure logs.
>> --
>> jacob walcik
>> jwalcik at mail.utexas.edu
>
> ----------------------------------------------------------------------- 
> -------
> Richard Barrett                                       
> http://www.openinfo.co.uk
>
>
--
jacob walcik
jwalcik at mail.utexas.edu