> smtp-failure:Aug 30 11:16:15 2000 (122) -1 <email addr> (ignore)
> (many, many times)
This means the SMTP agent (sendmail? You don't seem to say anything
about which MTA you're using, although I've been shockingly adept
as missing such hints lately) refused the delivery for that
user; the -1 is the "smtp_code" (or rather the lack of one) from
smtplib.py; the 'ignore' is the "smtp_error" (or lack of one)
from smtplib.py. See SMTPDirect.py's deliver() method for where
those things are set and accumulated in the refused dict.
Looks like the transaction was really unsuccessful, as in "couldn't
open a socket to the SMTP port at all".
> This user is in fact not getting email from either of the two lists
> he belongs to. The number in ()'s changes, though not with every
> entry in the logs.
> and, in logs/post, I see constant entries about:
> Aug 30 04:53:08 2000 (23571) post to <listname> from
> <listname>-request@<hostname>, size=28501, 177 failures
> (always the same number of failures and size; seems to be some sort
> of unrelated mail loop of some kind.)
Maybe; could be a digest post, for which 177 are failing. How
many digest members are there? (bin/list_members -d <list> | wc -l)
> and there are posts that go through:
> Aug 30 04:44:42 2000 (23411) post to <listname> from <some
> subscriber's email address>, size=528, success
> Now, this mystery "177 failures" message shows up again:
> Aug 30 06:50:10 2000 (25068) All recipients refused: please run connect()
That definitely means that you couldn't open a connection to the SMTP
port, for whatever reason. Is your MTA going up and down? JC's
question about "what does your MTA say" is a good one.
Also, running qrunner by hand and watching what it does, either by
sniffing network traffic on port 25 or system-call-tracing, would be
illuminating, I'm sure.
> Aug 30 06:50:10 2000 (25068) smtp for 177 recips, completed in 2.620 seconds
> In logs/bounce, I'm not sure I understand the meanings:
> Aug 29 23:13:31 2000 (18077) <listname>: <someuser> - 27 more allowed
> over 426977 secs
> then there will be:
> Aug 29 23:13:33 2000 (18077) <listname>: <differentuser> - 0 more
> allowed over 395006 secs
They both mean the same thing: that many more bounces will be allowed over
that time period before the user is considered for bounce removal
action (which might be "disable", or "notify", or "remove". Mostly
normal; there are always lots of bounces.
> The non-delivery problem affects digest and non-digest users.
> Archives are working fine. One list is 1,500 people; 500 normal,
> 1000 digest users; the other is about 100 people, mostly non-digest.
> We're using sendmail, and I have the threaded delivery turned on
This means you have a Python that supports threads, correct?
I have no experience with such a setup. I split them into chunks
with a patch to SMTPDirect.py which I hope to get Barry to look at
soon, authored by someone on one of these lists whose name I have
lost...SMTP_CHUNKIFY is a good unique string to look for it.
> Thanks all for any help/tips. I wouldn't mind applying some patches
> that have been introduced since 2.0b5 that will fix this stuff, if
> they're available.
This all sounds a lot more like MTA issues than Mailman; I'd focus
debug efforts there.