Very strange issue With Mailman + Exchange(?)
![](https://secure.gravatar.com/avatar/91d4ad5d2d8c192b3d6d683f40eb80e8.jpg?s=120&d=mm&r=g)
I am not sure how to figure this out.
Lengthy explanation:
Internally in our Exchange server, that address is a distribution group whose only member is the actual <list-name>@lists.pharmacy.arizona.edu, because the Mailman server is not our mail server. (we have a mildly complicated setup: hybrid OnPrem and O365 exchange + Barracuda spam appliance in front of all of it, which is our actual SMTP server.
Outgoing email from the list server bypasses Exchange and is sent directly to the Barracuda SMTP server.
For two users and ONLY these two users, somewhere between them and mailman and back, the Mailman list is being expanded to put all the members of the list on the CC line. It then gets held for approval with a ’too many addresses’ message.
I have watched them send an email to the affected list; the list address is NOT in their local address cache, and they are NOT entering any other addresses in the email other than the list address. The only address that appears on the email in their Sent folder is the list address.
Other users in our organization can send to these same lists without this happening. In fact one of the affected users can send to *other* lists on our server with no problems. These are two different lists.
I don’t know that this is specifically a Mailman problem (because it’s only happening with specific users) but I cannot see how list members are getting stuffed on the CC line otherwise; because Exchange only knows the list address, not the members; only Mailman does.
TLDR: Somehow the all the list addresses are getting stuck onto the list message which then holds it for approval for ’too many addresses’.
-- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group
Institutions do not have opinions, merely customs
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 4/27/20 11:21 AM, Bruce Johnson wrote:
I'm really guessing here, but I suspect that the list is not VERPing or personalizing delivery and the default setting for SMTP_MAX_RCPTS is not overridden with a small number.
In this case Mailman will send the outgoing message in only a few SMTP transactions with lots of recipients each. In fact, if this is and internal list and all the recipients are all in the same TLD, Mailman will send to all the recipients in one transaction with multiple RCPT TO commands. I.e., the envelope recipients for the message will be the whole list, at least if there are fewer than 500 members.
Some MUAs will add the envelope recipients to an X-Apparently-To: header and I wouldn't put it past Exchange to put them in Cc: even though this could effectively break Bcc:.
All that notwithstanding, this is the outgoing message, and IIUC the message never gets posted to the list, unless there's some convoluted process which reflects the outgoing message back to the list.
I would start by examining the Received: chain in the headers of the held message to see where it's been.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/91d4ad5d2d8c192b3d6d683f40eb80e8.jpg?s=120&d=mm&r=g)
Just posting this for the record in case any other person is unlucky enough to run into this…it turns out that the culprit in this case was the Zoom Outlook plug-in, when dealing with changing, deleting or adding to existing scheduled meeting instances (for instance biweekly faculty meetings were originally scheduled and sent as outlook invites to the mailman list. I finally caught how this was happening when another one of our people ran into it and noticed it only happened to the messages that had to do with Zoom meetings.
I do not know the full details of the issue yet, but I'm guessing that Zoom tried to be oh-so-clever, went back to THEIR servers, retrieved and appended the email addresses for the people who had logged into the meetings associated with that Exchange event record in the past. Altering or deleting a simple calendar event in Exchange does not do this, so it’s not anything on the Exchange side of things.
There appears to be no way of changing this on a quick perusal of the settings and Zoom is retiring the outlook plugin for a different architecture built into O365, I do not know yet if it continues the bug, but I'm sure I’ll find out as our entire campus is heavily invested in both Outlook and Zoom especially this fall.
-- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group
Institutions do not have opinions, merely customs
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 4/27/20 11:21 AM, Bruce Johnson wrote:
I'm really guessing here, but I suspect that the list is not VERPing or personalizing delivery and the default setting for SMTP_MAX_RCPTS is not overridden with a small number.
In this case Mailman will send the outgoing message in only a few SMTP transactions with lots of recipients each. In fact, if this is and internal list and all the recipients are all in the same TLD, Mailman will send to all the recipients in one transaction with multiple RCPT TO commands. I.e., the envelope recipients for the message will be the whole list, at least if there are fewer than 500 members.
Some MUAs will add the envelope recipients to an X-Apparently-To: header and I wouldn't put it past Exchange to put them in Cc: even though this could effectively break Bcc:.
All that notwithstanding, this is the outgoing message, and IIUC the message never gets posted to the list, unless there's some convoluted process which reflects the outgoing message back to the list.
I would start by examining the Received: chain in the headers of the held message to see where it's been.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/91d4ad5d2d8c192b3d6d683f40eb80e8.jpg?s=120&d=mm&r=g)
Just posting this for the record in case any other person is unlucky enough to run into this…it turns out that the culprit in this case was the Zoom Outlook plug-in, when dealing with changing, deleting or adding to existing scheduled meeting instances (for instance biweekly faculty meetings were originally scheduled and sent as outlook invites to the mailman list. I finally caught how this was happening when another one of our people ran into it and noticed it only happened to the messages that had to do with Zoom meetings.
I do not know the full details of the issue yet, but I'm guessing that Zoom tried to be oh-so-clever, went back to THEIR servers, retrieved and appended the email addresses for the people who had logged into the meetings associated with that Exchange event record in the past. Altering or deleting a simple calendar event in Exchange does not do this, so it’s not anything on the Exchange side of things.
There appears to be no way of changing this on a quick perusal of the settings and Zoom is retiring the outlook plugin for a different architecture built into O365, I do not know yet if it continues the bug, but I'm sure I’ll find out as our entire campus is heavily invested in both Outlook and Zoom especially this fall.
-- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group
Institutions do not have opinions, merely customs
participants (2)
-
Bruce Johnson
-
Mark Sapiro