Bretton Vine sent the message below at 14:22 8/30/2006: >Dragon said the following on 2006/08/30 10:03 PM: > > Oops... forgot to send my reply to the list too. Sorry about that > > Bretton, I did not mean for you to receive it twice. > >Not a problem, and thanks for the reply ;-) >However it doesn't solve my problem of determining why a > TO: [EMAIL PROTECTED]; CC: [EMAIL PROTECTED] >resulted in "message has implicit destination error". >I can't seem to reproduce the incident myself for some reason.
The TO: and CC: headers of an e-mail are both treated as explicit destinations and should not trigger this behavior. The only type of implicit destination I am aware of is an address in a BCC: field. I just tested this on one of my lists. I sent an e-mail with the To: set to one of my other e-mail addresses and the CC: set to my list address. I did this with the require_explicit_destination setting both on and off. I did not receive an error, the post was not held. I had require_explicit_destination set to on for all of my lists in the past but I have changed that since we implemented some aggressive anti-spam measures on our server. It worked as advertised when I had it enabled. My personal opinion on this situation is that the user was not telling you the truth. Whether that was from forgetting or outright deception I have no way to know. The only other thing I can think of is that some other type of error resulted in the message being held. I will admit I am not overly familiar with the internals of mailman as I am just a (somewhat) knowledgeable user and not an active developer. However, I still cannot see how this could happen and cannot duplicate the behavior as I understand it. >(no criticism intended to developers, but I have to ask:) >Was this requested by users; were users involved in this decision; or was it >a case of developers deciding for users what they thought was best given the >environment of email/lists from the developer perspective? As I am not one of the developers and I was not using mailman when that feature was implemented, I cannot answer if there was any community input into that decision. However, the decision that was made seems quite logical to me. >I repeat, no criticism intended, I just need to be able to give a complete >answer and am anticipating the questions I'll be asked. :-) I don't really understand why this is a concern, to me it just doesn't make a difference. It is very easy to override the implicit destination behavior if it is not appropriate for your lists. I honestly think somebody is making a mountain of a mole hill here. > > Personally, I believe it to be a reasonable default. > >I don't disagree. However the documentation is clear that BCC'ing a list >will result in administrative oversight (if setting is'on'). But not very >clear as to why a TO:list;CC:3rd-party would result in the same by a post >from a list member who is authorised to post. > >In terms of the logs, the error is /exactly/ the same whether it's > > TO: list > CC: someone > >or > > TO: list > BCC: someone > >or > > TO: someone > BCC: list > >Yes, I'm being pedantic -- but an explanation of the principle doesn't >always answer what happens in practice. I know answers can't be sucked out >of thin-air, but perhaps this has come up before? >(or not and I need to look deeper) As I said above, this should never have happened as far as I can tell. I'm sure one of the developers with more knowledge about this will correct me if I am wrong. > > Of course, there is absolutely nothing stopping you from turning the > > setting off. You probably would want some pretty aggressive anti-spam > > filtering and possibly graylisting enabled on your incoming queue of > > your MTA if you do that. > >We've found relatively little spam making it to any lists as it is. By just >how much a margin will turning the setting off impact on posts from >non-members reaching the list is non-member posting is already disallowed? >Is it just theoretical, negligible or will have it have major impact? If you set the default non-member action to Hold, no posts from non-members will get through unless a moderator explicitly approves them. If your spam filtering is good enough to keep examining the held messages from being an excessive work load, then by all means, disable the setting. The only potential problem I see, and it is a difficult one to solve, is with e-mails with forged sender addresses that match list member addresses. These e-mails will get through to the list. Since the use of the BCC: with a forged FROM: address is a common spammer tactic, it will result in some unwanted noise. How often that would happen is anyone's guess. How tolerable the problem would be is also anyone's guess. Just be aware that such things do tend to increase list-member dissatisfaction and the more volatile/vocal members may comment upon such things on the list. This was one of the driving forces behind my lists migrating from an older version of majordomo to mailman earlier this year. >In terms of our logs, the "message has implicit destination" occurs maybe >once for every 50 or so "post by non-member/unapproved-address to >member-only list" so if you look at it from a higher level service provider >approach it doesn't seem like it would make much of a difference, and >therefore is unnecessary to leave the setting enabled. That is one person's opinion, I would be willing to bet that most people who run members-only lists would disagree. >I don't quite agree, but it seems to be a point of view without a strong >counter-argument. And this is why this setting exists as an option. Dragon ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Venimus, Saltavimus, Bibimus (et naribus canium capti sumus) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------ 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