[Mailman-Users] Message received by mailman and archives, but won't deliver

[Kyle Banerjee]

Just in case someone else experiences insanely slow delivery, DNS
verifies on mail from mailman turned out to be the problem in my case.
I turned that off and made sure I could relay from localhost, and
everything works great.

kyle

On 8/30/07, Mark Sapiro <msapiro at value.net> wrote:
> Kyle Banerjee wrote:
> >
> >I've sent a few messages to the lists over the past couple hours. Here
> >is what I'm seeing:
> >
> >1) The files are appearing almost immediately in qfiles/out/ where
> >they seem to stay. Nothing is in retry or the other qfiles
> >directories.
> >
> >2) Even a couple hours later, nothing shows up in post, smtp, or
> >smtp-failure. However, someone who belonged to one of the lists sent
> >one through. I found the entry
> >
> >Aug 31 02:18:53 2007 (40546)
> ><01F67337-E566-4AA4-B684-01C9E2F3F9FB at mac.com> smtp to innopac for
> >2014 recips, completed in 11231.212 seconds
> >
> >The amount of time for the transaction seems insane. Load is
> >practically nonexistent.
>
>
> Your SMTP delivery to sendmail is incredibly slow. This is your entire
> problem. Your out queue is hoplessly backlogged due to the time it is
> taking to process SMTP. You will never catch up.
>
> You need to make changes in sendmail. See
> <http://www.python.org/cgi-bin/faqw-mm.py?query=performance&querytype=simple&casefold=yes&req=search>,
> particularly 4.11 and 6.3, and make sure you are not doing DNS
> verifies on mail from Mailman.
>
>
> >3) When I send a message to the list, maillog makes it look like
> >everything happened. For example, if I send it to the list with 4
> >people in it
> >
> >Aug 31 02:47:54 innopacusers sm-mta[52010]: l7V2lmww052010:
> >from=<namedeleted at gmail.com>, size=5888, class=0, nrcpts=1,
> >msgid=<47eed6660708301947g661c9557ocaeb52af48e48260 at mail.gmail.com>,
> >proto=ESMTP, daemon
> >=MTA-v4, relay=wa-out-1112.google.com [209.85.146.180]
>
>
> This doesn't look like a message from Mailman. A message from a mailman
> list will normally be from listname-bounces at example.com
> (webguru-bounces at innopacusers.org in this case). And, if this came
> from Mailman, there would be entries in Mailman's post and smtp logs.
>
>
> >Aug 31 02:48:01 innopacusers sm-mta[52012]: l7V2lmww052010:
> >to=namedeleted2 at bus.umich.edu, delay=00:00:07, xdelay=00:00:02,
> >mailer=esmtp, pri=156118, relay=bus-ex02.bus.umich.edu.
> >[141.211.239.195], dsn=2.0.0, stat=Sent (
> ><47eed6660708301947g661c9557ocaeb52af48e48260 at mail.gmail.com> Queued
> >mail for delivery)
> >Aug 31 02:48:02 innopacusers sm-mta[52012]: l7V2lmww052010:
> >to=namedeleted3 at Colorado.edu , delay=00:00:08
> >, xdelay=00:00:01, mailer=esmtp, pri=156118, relay=mx10.colorado.edu.
> >[128.138.128.110], dsn=2.0.0, stat=
> >Sent (Ok: queued as 31AB7C4A4B0)
> >Aug 31 02:48:03 innopacusers sm-mta[52012]: l7V2lmww052010:
> >to=namedeleted4 at gmail.com, delay=00:00:09, x
> >delay=00:00:01, mailer=esmtp, pri=156118,
> >relay=gmail-smtp-in.l.google.com. [64.233.167.27], dsn=2.0.0,
> >stat=Sent (OK 1188528483 a70si1963649pye)
> >Aug 31 02:48:04 innopacusers sm-mta[52012]: l7V2lmww052010:
> >to=fleckn at mail.lib.msu.edu, delay=00:00:10, x
> >delay=00:00:01, mailer=esmtp, pri=156118,
> >relay=mail1.mail.lib.msu.edu. [35.8.223.61], dsn=2.0.0, stat=Sent (
> ><47eed6660708301947g661c9557ocaeb52af48e48260 at mail.gmail.com> Queued
> >mail for delivery)
> >Aug 31 02:48:22 innopacusers sm-mta[52012]:
> >l7V2lmww052010:to=namedeleted5 at oregonstate.edu, delay=00:00:28,
> >xdelay=00:00:18, mailer=esmtp, pri=156118,
> >relay=relay.oregonstate.edu. [128.193.15.33], dsn=2.0.0, stat=Sent
> >(Ok: queued as 5D01C410AE6)
> >
> >The handoff to mailman shows up and it appears in /qfiles/out
> >Aug 31 02:40:58 innopacusers sm-mta[51781]: l7V2ep7j051777:
> >to="|/usr/local/bin/stripmime.pl|/usr/local/mailman/mail/mailman post
> >webguru" , ctladdr=<webguru at innopacusers.org> (26/0), delay=00:00:01,
> >xdelay=00:
> >00:01, mailer=prog, pri=31857, dsn=2.0.0, stat=Sent
>
>
> Mailman can do content filtering with I think more control than
> stripmime.pl
>
>
> >> In fact, in a well running Mailman installation qfiles/out/ is normally
> >> empty except for the occasional entry you see for a second or so while
> >> it's waiting to be picked up. (In 2.1.9, it will remain longer as a
> >> *.bak file while it is being processed by
> >> OutgoingRunner/SMTPDirect.py.)
> >>
> >> If *.pck files are hanging around in qfiles/out/, either there is a
> >> backlog (probably due to a configuration issue if it persists), or
> >> there is some problem with OutgoingRunner.
> >
> >This sounds like my problem. OutgoingRunner is running
> >
> >mailman 40546  0.0  1.7 19204 17236  ??  S    11:11PM   0:01.49
> >/usr/local/bin/python2.4 /usr/local/mailman/bin/qrunner
> >--runner=OutgoingRunner:0:1 -s
> >
> >I can easily buy that there's a config issue, but the strange thing is
> >that we were functional for years and all of a sudden quit working
>
>
> What Mailman version is this?
>
>
> >(having said that, we have a hosted server, so it's conceivable
> >something was done to our machine -- it's happened before).
> >
> >I don't understand how OutgoingRunner works -- any suggestions for
> >directions for me to explore in seeing if my sendmail or mailman
> >config is screwing things up? Thanks,
>
>
> OutgoingRunner picks up the oldest qfiles/out/*.pck file, gets the
> message and metadata from it and passes them to SMTPDirect.py for
> processing. When SMTPDirect.py returns, it picks up the next entry and
> repeats until there are no entries left. Then it sleeps for
> QRUNNER_SLEEP_TIME (default 1 second) and looks for any new entries.
>
> That's the basic flow assuming no errors or exceptions.
>
> See the above FAQ articles.
>
> --
> Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
>
>


-- 
----------------------------------------------------------
Kyle Banerjee
Digital Services Program Manager
Orbis Cascade Alliance
banerjek at uoregon.edu / 541.359.9599