Barry Warsaw writes: > I think you're both right :). Mailman 2.1 will strip recipients from > the CC header if explicitly named recipients are members of the list > and have nodup set. But Mailman won't strip To headers, nor juggle > CC and To headers after stripping.
Ah, right. I rarely see multiple addresses in the To header from @AOL though, so this should be sufficient. I have never seen multiple addresses in From (except in the examples section of RFC 822 :-), so that means that at most one will leak per reply. > It may not be a bad idea to go all the way with this as Sven > suggests, at least when not munging. I do think it will address a > common complaint about no-munge, and one that's harder to write off > as "fix your MUA". I see your point, but why won't my suggestion of defaulting the per user no-dupes to "on" do fine from that point of view? Thing is, my experience has been that people who care much about their personal setting invariably want it *on* (the ones who care and want it off use procmail anyway; those who can't or won't use procmail chalk it off as Insh'allah). That's neither here nor there, except that they would be very unhappy if the option were administratively removed (and I would be unhappy too, "ben" is "one of *them*", and what if "jwz" or "mly" were? Ouch!) I think it would be reasonable to remove *all* no-dupes members, and if the addressees end up empty, then put the list address in To: (or does Mailman already force the list to appear explicitly ... I guess not, since that's one of the addressee filters). _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
