Setup: Debian AMD64 (mix testing/stable), Exim 4.62, Mailman 2.1.8 from source (with patch to allow @listname in allowed posters), multiple installations of Mailman (one instance of MM per virtual domain)
In the last 24 hours we've had the same situation occur with two corporate clients. [case 1] List-member (and host of an INX) sent notification to a network-notices list with a CC to one of their employees. The message was held for administrative approval with the error: "message has implicit destination" + they are a member, have allowance to post to list + they claim no BCC in their message + virtualdomain1 [case 2] List-member sends message to [EMAIL PROTECTED] and BCC's [EMAIL PROTECTED] The message was held for administrative approval with the error: "message has implicit destination" + they are a member, have allowance to post to list + they indicated BCC to second list in follow-up query, problem resolved and message approved for second list Now in [case 1] we are being held accountable for the 24 hour delay in responding by authorising the post. This is a critical matter as it impacts on local Internet infrastructure, but due to the number of lists and virtualdomains it's simply impossible to have immediate notification for /every/ administrative request for every list. A once-a-day notification is one of many as it is and I (or my boss) spend up to an hour a day each morning just dealing with (mostly spam, non-member) administrative requests. Now I've already notified client of the reasons (with links to FAQ etc) over why the "message has implicit destination" error occurs, and switched it off for that list in particular. What I need though is a concise and accurate answer as to why this is the default setting in a Mailman installation. I understand the reason, but I need a non-technical, max 4 line rationale. Failing that I've been instructed to switch it off for /all/ the lists we host for corporate clients. Mind you that instruction stands regardless. What confuses me though is that in [case 1] the list-member claims to have sent the message as: TO: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] In [case 2] it was clearly: TO: [EMAIL PROTECTED] BCC: [EMAIL PROTECTED] But both instances resulted in the same administrative delay. So I'm a little confused. In terms of the info I can find online, there is no reason [case 1] should have resulted in an error /unless/ the list member had also included some BCC: addresses, which they claim not to have done. In [case 2] the error was quickly explained and rectified and the client happy. Obviously in [case 1] it's a slightly different story as due to the delay in notification/approval our national peering infrastructure had problems and someone needs to be held accountable -- in this case me :-) i.e. What happened, don't let it happen again. Now when I test the following I /don't/ get the error. TO: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Which brings to mind an obvious possibility, but this being what it is that isn't one that can be entertained. (heads must roll! <chuckles>) The configuration for all MM virtual domains is the same (barring domain specifics) and the configuration is highly tweaked to our environment based on online documentation relating to Mailman and Exim. Can anyone shed some light (and yes, I've googled and gone through numerous FAQ answers which have bought me some time but not a reason why the default installation behaviour is as it is for BCC to lists etc) -- | Bretton Vine | 083 633 8475 | [EMAIL PROTECTED] | | GPG: http://bretton.hivemind.net/bretton_vine.asc | "All men who have turned out worth anything have had the chief hand in their own education." - Sir Walter Scott ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp