I have to impossible dream of have *all* the mailing lists on my server work. So far one of the previously working lists continues to evade all methods of retrieving useful debug information... The other lists on the same server/domain currently seem to be OK, so the only conclusion I have is it's the number of subscribers or my provider is blocking emails out. Digests for the problem list still seem to go out every day. The original problem seemed to be RBL related, but that problem has either been solved or well obscured... Server info: Intel(R) Xeon(R)CPU 5110 @ 1.60GHz Red Hat Fedora Core 7, Linux 2.6.9-023stab043.1-smp Parallels Plesk 9.2.3 Mailman 2.1.9
What hasn't worked:
- My service provider claimed the info in disable messages was insufficient for debug!?
- I tried to bypass bounce processing by changing the list-bounces alias. Plesk fixed the alias.
- I reduced the bounce threshold, now people are kicked off sooner. Today's batch of almost 200 disables returned no useful information! All returned:
VERP worked a couple times on my test list, but never on the other lists, even though *sometimes* it did send the messages individually from the standard list-bounce address. I set VERP options: VERP_PERSONALIZED_DELIVERIES = Yes VERP_DELIVERY_INTERVAL = 1
tried to update from 2.1.9 to 2.1.12, but Mailman requires the Python development package. The latest Python won't install for some obscure reason... (Why my PC running Linux has Python dev. and will install Mailman and the server services I *PAY* for won't is a baffling question...)
couldn't find any useful information in the logfiles.
Have I mentioned that I'm frustrated and likely have ~450 annoyed list members by now? Not to mention that every piece of SPAM on the planet seems to have no problem finding it's way to <list>-owner@mydomain... :-/
Hopefully someone has a hint that might help me find a resolution to the problem....
John
John wrote:
And can you post one?
Because there was no 'triggering' bounce. The disable occurred because the threshold was reduced to a value <= the current score for these 200.
Did you restart Mailman after changing those settings in mm_cfg.py?
Anything in smtp-failure?
Does the smtp log say it delivered the post to the appropriate number of recipients?
Hopefully someone has a hint that might help me find a resolution to the problem....
Show us a disable message with an actual triggering bounce.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
answers inline...
Mark Sapiro wrote:
This was around the time my provider changed the smart host pool... The 64.202.189.86 IP address was in the pool & on at least 2 RBLs. The 208.109.80.54 IP is in the new pool and apparently still on 1 RBL list :-(. They claim they did not bounce back to my server... I haven't seen this since 11/10, but the rx7 list email is not being delivered. I don't understand why my other lists seem to be unaffected...
List: rx7
Member: username@aol.com
Action: Subscription disabled.
Reason: Excessive or fatal bounces.The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at mailman@rx7-world.net.
<username@sc.rr.com>: 64.202.189.86 failed after I sent the message. Remote host said: 554 Message refused.
long list of similar msgs removed...<username@aol.com>: 208.109.80.54 failed after I sent the message. Remote host said: 554 Message refused.
That makes sense, since I changed the bounce threshold...
I don't remember, but I did now...
empty
Does the smtp log say it delivered the post to the appropriate number of recipients?
it's hard to say... there is no single entry for the problem list that has the correct number (446 less a few nomail). I also don't know what the items are per line. I assume it's: timestamp, (???), msg ID, info -> Nov 12 03:45:42 2009 (32441) <mailman.3.1258026341.7724.rx7@rx7-world.net> -> smtp to rx7 for 1 recips, completed in 0.135 seconds
What's the value in ()'s? It doesn't seem to be msg length...
Hopefully someone has a hint that might help me find a resolution to the problem....
Show us a disable message with an actual triggering bounce.
see above...
Thanks, John
John wrote:
They aren't bouncing to your server. They are refusing to accept the message from your server. The fact that those IPs may be in RBLs is not relevant, because that would only affect delivery from them to the destination, and they aren't accepting the mail from you in the first place.
If it's only one list, it might have something to do with the smarthost not liking the particular rx7-bounces@... envelope sender. That's about the only thing that's list specific except maybe list size.
You have not included the headers of this notification message part , but presumably it came from your own MTA.
And as you know, those IPs are servers in the secureserver.net domain which presumably are the smarthost through which you're relaying and it is these servers that are refusing to accept the message from you.
How do you authenticate to these servers? Why should they accept and relay your mail?
What are the recipient numbers in the entry(s) for the message-id of a post?
It's the PID of the OutgoingRunner that logged the message. Also, the message-id in the above entry is a Mailman generated message of some kind, e.g. an owner notification or a held or rejected post message.
the '3' is a sequence number, the 1258026341 is a time stamp (seconds since the epoch) and 7724 is the PID of the process that generated the message as opposed to 32441, the PID of the process that delivered the message
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
I found a detailed bounce in my collection from before I entered a support ticket about RBLs at the beginning of Oct.
k2smtpout05-01.prod.mesa1.secureserver.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out.
<user@takas.lt>: 212.59.31.115 does not like recipient. Remote host said: 554 5.7.1 Service unavailable; Client host [64.202.189.56] blocked using dnsbl-1.uceprotect.net; IP 64.202.189.56 is UCEPROTECT-Level 1 listed. See http://www.uceprotect.net/rblcheck.php?ipr=64.202.189.56 Giving up on 212.59.31.115.
Maybe I'm just paranoid, but I smell a cover-up... Soon after the support ticket, I started receiving the summarized failures and bounces from the smart host... :-/ It's a lot easier to deny an email delivery problem if you return a vague bounce message instead of the real thing...
hmmm ... 'cause they accept and relay everything else from the server? :-P (ya gotta have some fun when things go wrong or else you'll go nuts. ;-) )
If VERP is on won't there only be 1 recipient/message-id, but multiple message-ids/post to Non-digest members? I also can't find a match to the received message IDs. It looks like digest is different, 2 entries totaling 262 "recips"...
For now, I'm going to assume (ouch) that it's my provider's problem. Thanks for all for the patience and answers. If nothing else, I learned more about the workings of Mailman & qmail. :-D I may try shutting off the RFC headers on the lists and see if that changes anything...
John
John wrote:
It is possible that the smarthost started using some kind of look-ahead address verification during incoming SMTP. I.e. they check that the message is deliverable downstream before accepting it from you and if it's not, return a generic "554 Message refused."
Note that in the case of the above, they accepted the message from you and then later sent an email reporting the delivery failure.
In the case of the "554 Message refused." reports you quoted earlier, they were refusing to accept the message during SMTP from you.
But why? If I attempt to connect to port 25 on the server at 208.109.80.54, it immediatly closes the connection without sending a greeting. Why doesn't it do this to you? There are lots of possibilities, e.g.
- your IP is a known 'good guy' in it's network
- you are connecting to some other port
- you are connecting via SSL with a certificate it recognizes as a customer
- other possibilities
I ask why, because the answer might have some bearing on the problem we're trying to understand/solve.
The individual (non-digest) messages are all the same message with the original message-id. The message may be delivered to the MTA by the SMTPDirect.py module in multiple transactions or even (with VERP) in transactions with a single recipient and a unique envelope sender, but there is still only one smtp log entry written by Mailman with the total number of recipients delivered to the MTA.
The message-id in a message received from the list should be logged in the smtp log.
Two entries per digest with Mailman generated message-ids is correct. one entry is for the plain format digest and one for the MIME format digest. These are separate messages with distinct contents, thus two messages. These may have been delivered to the MTA in multiple transactions or VERPed, but there are still only one log entry for the plain digest and one for the MIME digest.
There is some reason why this only affects one list. The question is why does the smarthost see mail from this list differently? Does the smarthost rate-limit you? I.e. does it reject all but the first 300 recipients in an hour or something like that?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
This morning I checked the smtp log to see if I could find a match to my daily ping. I did find it today, 1 entry for 156 members. And I got 156 summarized bounces with 554 errors. :-/ I'm going to try renaming the list or creating a new one with the same members to see what happens...
John
Mark Sapiro wrote:
John wrote:
Do I understand correctly that you have a local MTA that uses the smarthost as a relay, and Mailman delivers to the local MTA? If so, is there anything interesting in the MTA's logs?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Update: The smart host rejection problem that was affecting only 1 of the Mailman lists on my server was fixed by my provider. No explanation or email notifying me of the fix was provided... it just started working again Friday morning.
Thanks all for you input, John
John wrote:
And can you post one?
Because there was no 'triggering' bounce. The disable occurred because the threshold was reduced to a value <= the current score for these 200.
Did you restart Mailman after changing those settings in mm_cfg.py?
Anything in smtp-failure?
Does the smtp log say it delivered the post to the appropriate number of recipients?
Hopefully someone has a hint that might help me find a resolution to the problem....
Show us a disable message with an actual triggering bounce.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
answers inline...
Mark Sapiro wrote:
This was around the time my provider changed the smart host pool... The 64.202.189.86 IP address was in the pool & on at least 2 RBLs. The 208.109.80.54 IP is in the new pool and apparently still on 1 RBL list :-(. They claim they did not bounce back to my server... I haven't seen this since 11/10, but the rx7 list email is not being delivered. I don't understand why my other lists seem to be unaffected...
List: rx7
Member: username@aol.com
Action: Subscription disabled.
Reason: Excessive or fatal bounces.The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at mailman@rx7-world.net.
<username@sc.rr.com>: 64.202.189.86 failed after I sent the message. Remote host said: 554 Message refused.
long list of similar msgs removed...<username@aol.com>: 208.109.80.54 failed after I sent the message. Remote host said: 554 Message refused.
That makes sense, since I changed the bounce threshold...
I don't remember, but I did now...
empty
Does the smtp log say it delivered the post to the appropriate number of recipients?
it's hard to say... there is no single entry for the problem list that has the correct number (446 less a few nomail). I also don't know what the items are per line. I assume it's: timestamp, (???), msg ID, info -> Nov 12 03:45:42 2009 (32441) <mailman.3.1258026341.7724.rx7@rx7-world.net> -> smtp to rx7 for 1 recips, completed in 0.135 seconds
What's the value in ()'s? It doesn't seem to be msg length...
Hopefully someone has a hint that might help me find a resolution to the problem....
Show us a disable message with an actual triggering bounce.
see above...
Thanks, John
John wrote:
They aren't bouncing to your server. They are refusing to accept the message from your server. The fact that those IPs may be in RBLs is not relevant, because that would only affect delivery from them to the destination, and they aren't accepting the mail from you in the first place.
If it's only one list, it might have something to do with the smarthost not liking the particular rx7-bounces@... envelope sender. That's about the only thing that's list specific except maybe list size.
You have not included the headers of this notification message part , but presumably it came from your own MTA.
And as you know, those IPs are servers in the secureserver.net domain which presumably are the smarthost through which you're relaying and it is these servers that are refusing to accept the message from you.
How do you authenticate to these servers? Why should they accept and relay your mail?
What are the recipient numbers in the entry(s) for the message-id of a post?
It's the PID of the OutgoingRunner that logged the message. Also, the message-id in the above entry is a Mailman generated message of some kind, e.g. an owner notification or a held or rejected post message.
the '3' is a sequence number, the 1258026341 is a time stamp (seconds since the epoch) and 7724 is the PID of the process that generated the message as opposed to 32441, the PID of the process that delivered the message
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
I found a detailed bounce in my collection from before I entered a support ticket about RBLs at the beginning of Oct.
k2smtpout05-01.prod.mesa1.secureserver.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out.
<user@takas.lt>: 212.59.31.115 does not like recipient. Remote host said: 554 5.7.1 Service unavailable; Client host [64.202.189.56] blocked using dnsbl-1.uceprotect.net; IP 64.202.189.56 is UCEPROTECT-Level 1 listed. See http://www.uceprotect.net/rblcheck.php?ipr=64.202.189.56 Giving up on 212.59.31.115.
Maybe I'm just paranoid, but I smell a cover-up... Soon after the support ticket, I started receiving the summarized failures and bounces from the smart host... :-/ It's a lot easier to deny an email delivery problem if you return a vague bounce message instead of the real thing...
hmmm ... 'cause they accept and relay everything else from the server? :-P (ya gotta have some fun when things go wrong or else you'll go nuts. ;-) )
If VERP is on won't there only be 1 recipient/message-id, but multiple message-ids/post to Non-digest members? I also can't find a match to the received message IDs. It looks like digest is different, 2 entries totaling 262 "recips"...
For now, I'm going to assume (ouch) that it's my provider's problem. Thanks for all for the patience and answers. If nothing else, I learned more about the workings of Mailman & qmail. :-D I may try shutting off the RFC headers on the lists and see if that changes anything...
John
John wrote:
It is possible that the smarthost started using some kind of look-ahead address verification during incoming SMTP. I.e. they check that the message is deliverable downstream before accepting it from you and if it's not, return a generic "554 Message refused."
Note that in the case of the above, they accepted the message from you and then later sent an email reporting the delivery failure.
In the case of the "554 Message refused." reports you quoted earlier, they were refusing to accept the message during SMTP from you.
But why? If I attempt to connect to port 25 on the server at 208.109.80.54, it immediatly closes the connection without sending a greeting. Why doesn't it do this to you? There are lots of possibilities, e.g.
- your IP is a known 'good guy' in it's network
- you are connecting to some other port
- you are connecting via SSL with a certificate it recognizes as a customer
- other possibilities
I ask why, because the answer might have some bearing on the problem we're trying to understand/solve.
The individual (non-digest) messages are all the same message with the original message-id. The message may be delivered to the MTA by the SMTPDirect.py module in multiple transactions or even (with VERP) in transactions with a single recipient and a unique envelope sender, but there is still only one smtp log entry written by Mailman with the total number of recipients delivered to the MTA.
The message-id in a message received from the list should be logged in the smtp log.
Two entries per digest with Mailman generated message-ids is correct. one entry is for the plain format digest and one for the MIME format digest. These are separate messages with distinct contents, thus two messages. These may have been delivered to the MTA in multiple transactions or VERPed, but there are still only one log entry for the plain digest and one for the MIME digest.
There is some reason why this only affects one list. The question is why does the smarthost see mail from this list differently? Does the smarthost rate-limit you? I.e. does it reject all but the first 300 recipients in an hour or something like that?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
This morning I checked the smtp log to see if I could find a match to my daily ping. I did find it today, 1 entry for 156 members. And I got 156 summarized bounces with 554 errors. :-/ I'm going to try renaming the list or creating a new one with the same members to see what happens...
John
Mark Sapiro wrote:
John wrote:
Do I understand correctly that you have a local MTA that uses the smarthost as a relay, and Mailman delivers to the local MTA? If so, is there anything interesting in the MTA's logs?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Update: The smart host rejection problem that was affecting only 1 of the Mailman lists on my server was fixed by my provider. No explanation or email notifying me of the fix was provided... it just started working again Friday morning.
Thanks all for you input, John
participants (2)
-
John -
Mark Sapiro