Mailman 2.1.9 incorrectly holding messages for "Reason: Message has implicit destination"
We had been using mailman 2.1.5 installed on Redhat Enterprise v3.n for several years . A few months ago, we installed a new Redhat system for our mailing list server, Redhat Enterprise Linux Server release 5.3 (Tikanga) which has Mailman 2.1.9 installed. I followed various instructions on migrating the mailing lists and everything seemed to be working just fine. However, within the past few weeks we noticed that some users sending to their favorite lists are having a lot of trouble with their messages being held as: "Reason: Message has implicit destination" . Many users do not have this happen. I have been investigating and testing and I can not figure out why. Our main campus mail system is Exchange 2007. They have put the address in the correct place, i.e. The To: or CC: fields.
We create exchange contacts for each mailing list that forwards the message to the mailing list server, e.g. listname@stcloudstate.edu forwards to listname@lserver.stcloudstate.edu and there was never any problems for the past several years before our upgrade. Below is the header info from a message that is being held that should have passed through. Can anyone think of what is causing this behavior for certain messages? One person mentioned that it happenes when he did a reply-all to a message and it worked after creatomg a new message. I do not know if this could be related because I tried doing this and all my messages went through fine. I may have to experiment more with what email client software the messages are being sent from, I mostly use Entourage on a Mac. The majority of campus use Outlook on some version of Windows.
Thanks for any help Gordon Schmitt St. Cloud State University
Return-Path: <joesmoe@stcloudstate.edu> X-Original-To: listname@lserver.stcloudstate.edu Delivered-To: listname@lserver.stcloudstate.edu Received: from excserver1.campus.stcloudstate.edu (excserver1.campus.stcloudstate.edu [199.17.15.89]) by lists.stcloudstate.edu (Postfix) with ESMTP id 66C9E97745 for <listname@lserver.stcloudstate.edu>; Wed, 17 Jun 2009 14:55:52 -0500 (CDT) Received: from excserver2.campus.stcloudstate.edu ([199.17.15.82]) by excserver1.campus.stcloudstate.edu ([199.17.15.89]) with mapi; Wed, 17 Jun 2009 14:55:26 -0500 From: "Smoe, Joe A." <joesmoe@stcloudstate.edu> To: "Olagunju, Am O." <alguein@stcloudstate.edu>, "listname@stcloudstate.edu" <IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=listname@stcloudstate.edu> Date: Wed, 17 Jun 2009 14:55:25 -0500 Subject: RE: Remedial education requires joint partnerships Thread-Topic: Remedial education requires joint partnerships Thread-Index: Acnulm1RBSQvD3MvQeSh+5ZrkDCZkgA6JTO3 Message-ID: <3D401A37AB144C40AF0D9BE440596A7F12EA6C84EF@excserver2.campus.stcloudstate.edu> References: <16EEB76BD19BC343A7E6E591A3A4B82712E41B3061@excserver2.campus.stcloudstate.edu> In-Reply-To: <16EEB76BD19BC343A7E6E591A3A4B82712E41B3061@excserver2.campus.stcloudstate.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_3D401A37AB144C40AF0D9BE440596A7F12EA6C84EFSCSU80campuss_"; type="multipart/alternative" MIME-Version: 1.0
Schmitt, Gordon A. wrote:
Below is the header info from a message that is being held that should have passed through. Can anyone think of what is causing this behavior for certain messages? One person mentioned that it happenes when he did a reply-all to a message and it worked after creatomg a new message. I do not know if this could be related because I tried doing this and all my messages went through fine. I may have to experiment more with what email client software the messages are being sent from, I mostly use Entourage on a Mac. The majority of campus use Outlook on some version of Windows.
[...]
To: "Olagunju, Am O." <alguein@stcloudstate.edu>, "listname@stcloudstate.edu" <IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=listname@stcloudstate.edu>
Are the HTML entities (", < and >) actually in the message header or are they artifacts from some web copy/paste operation? Even assuming those are just an artifact, the above header is
To: "Olagunju, Am O." <alguein@stcloudstate.edu>, "listname@stcloudstate.edu"
<IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=listname@stcloudstate.edu>
What is all that "IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=" prepended to "listname" If that is what the To: header actially looked like, that's the problem.
I would not be surprised to find that Outlook did something to the address in the To: header of the reply that could cause this, but I haven't heard of it.
In another reply, Barry Finkel suggests adding listname@stcloudstate.edu to acceptable_aliases for the listname@lserver.stcloudstate.edu list. While this is a good idea, it will not solve the problem in this case, because as a deprecated, backwards compatibility feature, Mailman 2.1.x will accept any address as the list address if the list name matches even if the domains don't.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks for you response.
The text '.."listname@stcloudstate.edu"..' is copied from Mailman's Message Headers textbox of a held message and that is exactly how it appears in that textbox.
The "IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=" comes from the exchange server. It seems to show up that why for held moderated messages too(that pass through without problems).
I found out from another user today that it happens to them when they reply of forward a message to listname@stcloudstate.edu, but not if they create a new message. This is the second person that has informed me of this behavior. I plan to visit his office and observe what his Outlook is doing.
I already tried adding the listname@stcloudstate.edu as an acceptable alias (in fact I did it for all of our lists) and thought I had solved the problem but found out the next day that the same users were still having the same problem.
Are there any log files worth looking at, or additional mailman logging that I can setup that might be helpful?
Do you think the HTML entities could be causing the problem? Or more likely the <IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=listname@stcloudstate.edu>? Do either of these contain characters that would cause Mailman to not match "listname@stcloudstate.edu" even though it is in the string?
Thanks again
Gordon Schmitt St. Cloud State University
On 6/18/09 11:50 AM, "Mark Sapiro" <mark@msapiro.net> wrote:
Schmitt, Gordon A. wrote:
Below is the header info from a message that is being held that should have passed through. Can anyone think of what is causing this behavior for certain messages? One person mentioned that it happenes when he did a reply-all to a message and it worked after creatomg a new message. I do not know if this could be related because I tried doing this and all my messages went through fine. I may have to experiment more with what email client software the messages are being sent from, I mostly use Entourage on a Mac. The majority of campus use Outlook on some version of Windows.
[...]
To: "Olagunju, Am O." <alguein@stcloudstate.edu>, "listname@stcloudstate.edu" <IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=listname@stcloudstate.edu>
Are the HTML entities (", < and >) actually in the message header or are they artifacts from some web copy/paste operation? Even assuming those are just an artifact, the above header is
To: "Olagunju, Am O." <alguein@stcloudstate.edu>, "listname@stcloudstate.edu"
<IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=listname@stcloudstate.edu>
What is all that "IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=" prepended to "listname" If that is what the To: header actially looked like, that's the problem.
I would not be surprised to find that Outlook did something to the address in the To: header of the reply that could cause this, but I haven't heard of it.
In another reply, Barry Finkel suggests adding listname@stcloudstate.edu to acceptable_aliases for the listname@lserver.stcloudstate.edu list. While this is a good idea, it will not solve the problem in this case, because as a deprecated, backwards compatibility feature, Mailman 2.1.x will accept any address as the list address if the list name matches even if the domains don't.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-- Gordon Schmitt System Administrator/Programmer LRTS/ITS MC 204 St. Cloud State University Gordie _at_ stcloudstate.edu 320-308-4838
Schmitt, Gordon A. wrote:
The text '.."listname@stcloudstate.edu"..' is copied from Mailman's Message Headers textbox of a held message and that is exactly how it appears in that textbox.
Yeah, That's Mailman being overprotective against XSS attacks. The HTML entities are seen in the text box in the admindb interface, but the received message contains the actual characters, so that's not the problem.
The "IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=" comes from the exchange server. It seems to show up that why for held moderated messages too(that pass through without problems).
If you're saying you see this in messages held for some other reason (moderated member), and those messages pass through OK after approval, that means nothing. Moderation and non-member tests are done first followed by administrivia and "too many recipients" before "implicit destination. Once approved, a held message will not be held again for any reason. Thus, a message that meets the test for "implicit destination" can be held for "moderated member", "non-member post", "administrivia" or "too big", and if approved will then go to the list.
If that string is the problem, you could try adding to acceptable_aliases
^.*listname@(lserver\.)?stcloudstate\.edu$
(a regexp that matches anything ending in listname@stcloudstate.edu or listname@lserver.stcloudstate.edu) or if the last "=" is always there
^(.*=)?listname@(lserver\.)?stcloudstate\.edu$
which will match listname@stcloudstate.edu or listname@lserver.stcloudstate.edu possibly preceded with anything ending in "=".
I found out from another user today that it happens to them when they reply of forward a message to listname@stcloudstate.edu, but not if they create a new message. This is the second person that has informed me of this behavior. I plan to visit his office and observe what his Outlook is doing.
Also, have him Cc or Bcc you on an original message and a reply/forward so you can see what the To: and Cc: headers look like in the two cases.
[...]
Are there any log files worth looking at, or additional mailman logging that I can setup that might be helpful?
The only logging is Mailman's Vette log, and that doesn't show anything that isn't already in the admindb interface.
Do you think the HTML entities could be causing the problem? Or more likely the <IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=listname@stcloudstate.edu>? Do either of these contain characters that would cause Mailman to not match "listname@stcloudstate.edu" even though it is in the string?
The test is a match against the whole address so the only way to ignore the leading junk is with a regexp in acceptable_aliases such as the ones above that explicitly skips stuff at the beginning.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Here is an update/resolution to this problem. Unfortunately, the regexp in the Acceptable_Aliases did not solve the problem. I tested the regexp and it seemed to work as expected when I sent messages, I even expanded the wildcard searching parameters; however, when users who experienced the real problem sent messages, the problem persisted.
Solution discovered: Our Exchange administrator found a couple of recent posts reporting similar behavior/problems that showed up with Exchange 2007 Rollup 7 and were said to be resolved by installing the Exchange Server 2007 Rollup 8 (we were at Rollup 7). He installed Rollup 8 to our servers and the problem seems to be gone now.
-- Gordon Schmitt System Administrator/Programmer St. Cloud State University Gordie _at_ stcloudstate.edu
On 6/18/09 1:59 PM, "Mark Sapiro" <mark@msapiro.net> wrote:
Schmitt, Gordon A. wrote:
The text '.."listname@stcloudstate.edu"..' is copied from Mailman's Message Headers textbox of a held message and that is exactly how it appears in that textbox.
Yeah, That's Mailman being overprotective against XSS attacks. The HTML entities are seen in the text box in the admindb interface, but the received message contains the actual characters, so that's not the problem.
The "IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=" comes from the exchange server. It seems to show up that why for held moderated messages too(that pass through without problems).
If you're saying you see this in messages held for some other reason (moderated member), and those messages pass through OK after approval, that means nothing. Moderation and non-member tests are done first followed by administrivia and "too many recipients" before "implicit destination. Once approved, a held message will not be held again for any reason. Thus, a message that meets the test for "implicit destination" can be held for "moderated member", "non-member post", "administrivia" or "too big", and if approved will then go to the list.
If that string is the problem, you could try adding to acceptable_aliases
^.*listname@(lserver\.)?stcloudstate\.edu$
(a regexp that matches anything ending in listname@stcloudstate.edu or listname@lserver.stcloudstate.edu) or if the last "=" is always there
^(.*=)?listname@(lserver\.)?stcloudstate\.edu$
which will match listname@stcloudstate.edu or listname@lserver.stcloudstate.edu possibly preceded with anything ending in "=".
I found out from another user today that it happens to them when they reply of forward a message to listname@stcloudstate.edu, but not if they create a new message. This is the second person that has informed me of this behavior. I plan to visit his office and observe what his Outlook is doing.
Also, have him Cc or Bcc you on an original message and a reply/forward so you can see what the To: and Cc: headers look like in the two cases.
[...]
Are there any log files worth looking at, or additional mailman logging that I can setup that might be helpful?
The only logging is Mailman's Vette log, and that doesn't show anything that isn't already in the admindb interface.
Do you think the HTML entities could be causing the problem? Or more likely the <IMCEAEX-_O=SCSU_OU=First+20Administrative+20Group_cn=Recipients_cn=listname@stcloudstate.edu>? Do either of these contain characters that would cause Mailman to not match "listname@stcloudstate.edu" even though it is in the string?
The test is a match against the whole address so the only way to ignore the leading junk is with a regexp in acceptable_aliases such as the ones above that explicitly skips stuff at the beginning.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Mark Sapiro -
Schmitt, Gordon A.