[Mailman-Users] Mailman 2.1.9 incorrectly holding messagesfor"Reason: Message has implicit destination"

[Schmitt, Gordon A.]

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 at msapiro.net> wrote:

Schmitt, Gordon A. wrote:
>
>The text '..&quot;listname at stcloudstate.edu&quot;..' 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 at stcloudstate.edu or
listname at lserver.stcloudstate.edu) or if the last "=" is always there

^(.*=)?listname@(lserver\.)?stcloudstate\.edu$

which will match listname at stcloudstate.edu or
listname at 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 at 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 at stcloudstate.edu>? Do either of these contain characters that would cause Mailman to not match "listname at 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 at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan