[Mailman-Users] Analysis of reasons for bounce responses

[Christine De La Rosa]

Oh I forgot to add, that my dedicated is also a nameserver (domain.com)
with about 10 hosted domains (domain1.com, domain2.com...)

Chris

-----Original Message-----
From: Richard Barrett [mailto:r.barrett at openinfo.co.uk] 
Sent: Thursday, July 31, 2003 7:30 PM
To: Christine De La Rosa
Cc: 'Mailman'
Subject: Re: [Mailman-Users] Analysis of reasons for bounce responses


Chris

On Friday, August 1, 2003, at 12:48  am, Christine De La Rosa wrote:

> This is the EXACT problem I am having with mailman, using cpanel and 
> exim.  I, however, am on a dedicated box and have root access.  I have

> been working on this problem for over three weeks.  I am tired and 
> frustrated and wishing I knew a little more about mailman and its 
> inner workings.

As I said in my post, this bounce issue is not, in my view, at heart a  
bug in Mailman. The evidence I saw of bounce notices from local MTA  
(Exim) say that the MTA is having problems getting outgoing mail off  
the system and finally bouncing it back to Mailman when it fails to do  
so.

If you are getting final bounce notices from Mailman when it disables a

subscriber because of these problems what is the reason reported in the

bounce message from the MTA, which should be attached to the bottom of  
the final bounce notification from MM? In the example final bounce  
notice passed to me for comment the MTA was reporting it was having an  
IP routing problem; that is hardly a Mailman generated problem as far  
as I can tell.

One of my problems with looking at this is I am trying to help out a  
fairly new user with a problem I have not seen on my systems, while I  
have no access to the Mailman or MTA logs on a system experiencing the  
problem. I have no standing with the CPanel owners to raise matters  
with them in case they are contributing to the problem with the way  
they set things up. Deeply frustrating.

Let me know if you gain any insight or information related to this.

> I come from a majordomo background.  When I got this dedicated server,

> it had mailman pre-installed so I thought kewl I will use it instead.

> It ran fabulously until cpanel did their last upgrade. I have been in 
> hell since then.
>
> I wish I could help you, but I have not been able to figure out even 
> from the logs what the issues are.  Granted, looking at the logs are 
> like gobbledigook to me.  So I have spent a lot of time searching the 
> archives for this problem.  Although, I haven't been able to find
> anyone
> with my specific issue.  I can tell you that qrunner has been
consuming
> my cpu at astonishing rates.

Mailman can consume large amounts of CPU when the MTA it is trying to  
hand mail over to repeatedly returns temporary failures. MM can be too  
aggressive in repeatedly trying to get the MTA to either accept or  
permanently fail the handover. There are changes in the Mailman CVS to  
moderate MM's efforts in this respect but so far as I know those  
changes are not available as a patch for MM 2.1.2 stable. This issue  
may be affecting you but I am no expert myself in setting up Exim so as

to avoid this undesirable interaction; I do not see it with my Sendmail

setup. There have been posts to mailman-users on the topic of high CPU  
utilisation. This one fromJon Carnes relates to Postfix MTA but its  
substance/recommendations may be applicable to Exim:

http://www.mail-archive.com/mailman-users@python.org/msg17786.html

>  But there is no rhyme or reason to that,
> that I can see.  If I find anything out I will post it here.
>
> Chris
>
> -----Original Message-----
> From: mailman-users-bounces+chris=christinedelarosa.com at python.org
> [mailto:mailman-users-bounces+chris=christinedelarosa.com at python.org]
> On
> Behalf Of Richard Barrett
> Sent: Thursday, July 31, 2003 5:08 AM
> To: Mailman
> Subject: [Mailman-Users] Analysis of reasons for bounce responses
>
>
> This is not my problem but one soemone approached me about off list.
> I'll summarise their situation and I would appreciate any thoughts,
> comments, sanity checking on my analysis.
>
> Situation:
>
> 1. List admin's domain is hosted by a server run by a hosting company.
>
> 2. The server is (probably) running Linux
>
> 3. Mailman 2.1.2 is provided on the server with, I believe, CPanel
>
> 4. The server's MTA appears to be Exim 4.20 handling both incoming and
> outgoing messages to/from Mailman
>
> 5. Mailman list's basically work OK much of the time
>
> 6. Periodically messages out from Mailman are being bounced en masse
> leading to the subscriber accounts being disabled
>
> 7. The bounce response attached to the bounce action notice produced
by
>
> Mailman when subscribers are disabled in these circumstances is from
> the server local MTA. The MTA lists what appears to be all the
> addresses to which the outgoing message was sent with a note against
> each saying "unrouteable mail domain maildomain.tld". The bounce
> response asserts that this is a permanent failure. The messages are
> each being sent to a number of different mail domains not just a
single
>
> one
>
> 8. The list admin with the problem has no access to either the Mailman
> or MTA logs
>
> 9. The server administrator is supposedly claiming that these bounces
> are a result of "a bug in Mailman for which no patch is available"
>
> My analysis is:
>
> 1. The problem is not obviously due to any bug in Mailman
>
> 2. The problem is more likely due to an IP routing problem which
> periodically afflicts the server and its ability to reach the MTAs for
> the mail domains addressed by the outgoing messages
>
> 3. The MTA is accepting the outgoing messages from Mailman and then
> finding it has problems of its own in delivering mail which are
> unrelated to Mailman as the origin of the messages
>
> But I have to concede I know nothing about Exim 4.20. I know even less
> about CPanel.
>
> Any thoughts or anatomically feasible suggestions welcome.
>
>
----------------------------------------------------------------------- 
> -
>
> -----
> Richard Barrett
> http://www.openinfo.co.uk