Re: [Mailman-Users] yahoo.com.INVALID as a DMARC defense [was: 2.1.18 internal documentation suggestions]
Andrew Partan writes: Until people figure out real ways of making DMARC work with forwrders mailing lists (see ietf-...@ietf.org for one place discussions are going on), I think it useful to have more work-around hacks out there so that people can experiment with them to see which ones more-or-less work in different situations. That's what they said about Reply-To munging, too. If people want to implement them themselves and try them out, heck, I've been wrong before and I'll be wrong again. But I don't think *Mailman* should proactively implement RFC violations unless there's a clear and present danger, and then the violations should try to be minimal.[1] DMARC, since it causes denial of service to third parties, is such a clear and present danger. Here I interpret minimal to mean try to avoid to adding to the set of RFC violations out there. I know it's tempting to imply that yahoo.com is an invalid domain, but it's not at all necessary given that substituting the list-post address is what Yahoo itself suggests. The original user is easily replied to via the Reply-To hack. Footnotes: [1] Retroactive implementation, such as Reply-To munging, may be appropriate in response to customer demand. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] Parallel list question
I once set this up long ago on mailman but took it down and now need to do it again but forgot how: Want to have all subscribers to list A receive from, and be able to post to, list B. Purpose is to change the list title shown in the Subject: field, and have different admin options for list B. Thank you in advance. (And while I'm at it, thank you to those who have worked on the DMARC enhancements.) Rob Lingelbach http://colorist.org -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] new users added to custom MemberAdaptor don't get emails
Hi folks, I have a setup where lists are not open to be joined by anyone but are managed by an LDAP database. The database is queried once an hour and the members of each list are written to a file which is then read in whenever anything is posted to a list. My problem is that newly added members seem not to be recognized until I reboot the server. The strange part is that executing /usr/lib/mailman/bin/list_members gives the correct entries including any newly added members while no actual mails are sent to the new members (they don't receive the mails and there are no entries in /var/log/mail.log) until I reboot the server. I am guessing that the ldap part should be correct since list_members shows the correct entries. I am attaching the files /usr/lib/mailman/Mailman/FileMemberships.py and /var/lib/mailman/lists/testlist/extend.py, which should contain all the relevant information. If anyone is also interested in the part that polls the LDAP server, the whole code can be found at http://ldapsync.sourceforge.net/ Any help is appreciated. Regards, Viktor -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] 2.1.18 internal documentation suggestions
On Fri, 2014-05-02 at 22:25 -0700, Mark Sapiro wrote: On 05/01/2014 11:29 PM, Lindsay Haisley wrote: There may be a problem with being _too_ wordy in explaining it. Yes, and I may have gone there ;) Well I think you've pretty well covered the bases. It may take a bit of study on the part of list admins to understand it, but this is much improved over what it was. This is the kind of thing that people with experience in, or knowledge of structured programming can explain rather succinctly in logical pseudocode, but you're working with the more traditional prose style in which the rest of Mailman's internal docs are written, and a certain amount of redundant verbiage is probably inevitable. -- Lindsay Haisley | Everything works if you let it FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com| -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] new users added to custom MemberAdaptor don't get emails
On 05/02/2014 08:07 AM, Viktor Dick wrote: Hi folks, I have a setup where lists are not open to be joined by anyone but are managed by an LDAP database. The database is queried once an hour and the members of each list are written to a file which is then read in whenever anything is posted to a list. My problem is that newly added members seem not to be recognized until I reboot the server. The strange part is that executing /usr/lib/mailman/bin/list_members gives the correct entries including any newly added members while no actual mails are sent to the new members (they don't receive the mails and there are no entries in /var/log/mail.log) until I reboot the server. When you run list_members, it runs as a new, separate process so it gets the current version of the members from a new instance of the MemberAdaptor. However, Mailman's qrunner processes are persistent and they don't 'reload' unless Mailman is restarted. Apparently, once your MemberAdaptor thinks it has the membership list, it doesn't try to update it. Note that rebooting is overkill. Just restarting Mailman should suffice. I can't say more about what to do without actually seeing your MemberAdaptor, however you might look at https://bugs.launchpad.net/mailman/+bug/558106 for an alternative. I am attaching the files /usr/lib/mailman/Mailman/FileMemberships.py and /var/lib/mailman/lists/testlist/extend.py, which should contain all the relevant information. The list's content filtering removes non text/plain attachments. They will come through if you ensure they have a MIME Content-Type: of text/plain. Maybe naming them FileMemberships.py.txt and extend.py.txt will convince your mail client to do that. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Parallel list question
On 05/02/2014 03:41 PM, Rob Lingelbach wrote: Want to have all subscribers to list A receive from, and be able to post to, list B. Purpose is to change the list title shown in the Subject: field, and have different admin options for list B. Since you want the list A subscribers to get the list A subject_prefix for posts to list B, list A needs to be a member of (subscribed to) list B. You can't make list A a regular_include_list of list B because the members of list A would then see list B's subject_prefix in posts to list B. So list A is a member of list B. You need to be sure that list A's user options include no password reminders. You can't make list B an umbrella list (see http://wiki.list.org/x/boA9) because list B has regular members and an umbrella list has only lists as members. Then for list A members to be able to post to list B, you need @lista (or whatever it's name is) in list B's accept_these_nonmembers and for list B posts to not be held for implicit destination by list A, you need to put list B's address in list A's Privacy options... - Recipient filters - acceptable_aliases or turn off require_explicit_destination. (And while I'm at it, thank you to those who have worked on the DMARC enhancements.) Thanks from all of us for your appreciation. It's been an exciting month ... -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Parallel list question
I'd like to add my thanks as well... the folks who have contributed to the discussion and I'm guessing a large number behind the scenes have done (and continue to do) a great service... not just to Mailman but to users all over the world who have no idea of the dedication and effort of those of you below their radar. Thank you all. Best Regards, Mike -- Mike Starr, Writer Technical Writer -Online Help Developer - WordPress Websites Graphic Designer - Desktop Publisher - Custom Microsoft Word templates (262) 694-1028 - m...@writestarr.com - http://www.writestarr.com President - Working Writers of Wisconsin http://www.workingwriters.org/ On 5/3/2014 12:03 PM, Mark Sapiro wrote: (And while I'm at it, thank you to those who have worked on the DMARC enhancements.) Thanks from all of us for your appreciation. It's been an exciting month ... -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Parallel list question
On May 3, 2014, at 12:03 PM, Mark Sapiro m...@msapiro.net wrote: On 05/02/2014 03:41 PM, Rob Lingelbach wrote: Want to have all subscribers to list A receive from, and be able to post to, list B. Purpose is to change the list title shown in the Subject: field, and have different admin options for list B. Since you want the list A subscribers to get the list A subject_prefix for posts to list B, I should have been clearer that I do want list B's subject_prefix to change. I think I can work it out now based on your suggestions... Incidentally, this brings up (what might be considered) a sophomoric question: how to copy a list's config over to a test version of that list, without copying over the member list? Probably a FAQ that I should be aware of... Now back to understanding the conditions I should implement for an active 2000+ member list on the anvil of DMARC. Thanks again -- Rob Lingelbach http://colorist.org -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] Mailman 2.1.18 final release
I'm pleased to announce the final release for Mailman 2.1.18. This release has new features to help with mitigation of the impacts of DMARC on mailing lists as well as fixing several bugs. Python 2.4 is the minimum supported, but Python 2.7 is recommended. There are significant new i18n strings associated with the DMARC mitigation features. If you are interested in helping with the translations of these strings, see http://wiki.list.org/x/MQ. There is also a new dependency associated with these features. Namely, the new Privacy options - Sender filters - dmarc_moderation_action feature requires that the dnspython http://www.dnspython.org/ package be available in Python. See the attached README for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.18 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.18 (03-May-2014) Dependencies - There is a new dependency associated with the new Privacy options - Sender filters - dmarc_moderation_action feature discussed below. This requires that the dnspython http://www.dnspython.org/ package be available in Python. This package can be downloaded from the above site or from the CheeseShop https://pypi.python.org/pypi/dnspython/ or installed with pip. New Features - The from_is_list feature introduced in 2.1.16 is now unconditionally available to list owners. There is also, a new Privacy options - Sender filters - dmarc_moderation_action feature which applies to list messages where the From: address is in a domain which publishes a DMARC policy of reject or possibly quarantine. This is a list setting with values of Accept, Wrap Message, Munge From, Reject or Discard. There is a new DEFAULT_DMARC_MODERATION_ACTION configuration setting to set the default for this, and the list admin UI is not able to set an action which is 'less' than the default. The prior ALLOW_FROM_IS_LIST setting has been removed and is effectively always Yes. There is a new dmarc_quarantine_moderation_action list setting with default set by a new DEFAULT_DMARC_QUARANTINE_MODERATION_ACTION configuration setting which in turn defaults to Yes. The list setting can be set to No to exclude domains with DMARC policy of quarantine from dmarc_moderation_action. dmarc_moderation_action and from_is_list interact in the following way. If the message is From: a domain to which dmarc_moderation_action applies and if dmarc_moderation_action is other than Accept, dmarc_moderation_action applies to that message. Otherwise the from_is_list action applies. Also associated with dmarc_moderation_action are configuration settings DMARC_RESOLVER_TIMEOUT and DMARC_RESOLVER_LIFETIME. These are described in more detail in Defaults.py. There are also new vette log entries written when dmarc_moderation_action is found to apply to a post. i18n - Added missing mm-digest-question-start tag to French listinfo template. (LP: #1275964) Bug Fixes and other patches - Removed HTML tags from the title of a couple of rmlist.py pages because browsers don't render tags in the title. (LP: #265848) - Most Mailman generated notices to list owners and moderators are now sent as Precedence: list instead of bulk. (LP: #1313146) - The Reply-To: munging options weren't honored if there was no from_is_list action. (LP: #1313010) - Changed from_is_list actions to insert the list address in Cc: if the list is fully personalized. Otherwise, the list address is only in From: and Reply-To: overrides it. (LP: #1312970) - Fixed the Munge From action to only Munge the From: and/or Reply-To: in the outgoing message and not in archives, digests and messages sent via the usenet gateway. (LP: #1311431) - Fixed a long standing issue in which a notice sent to a user whose language is other than that of the list can cause subsequent things which should be in the list's language to be in the user's language instead. (LP: #1308655) - Fixed the admin Membership List so a search string if any is not lost when visiting subsequent fragments of a chunked list. (LP: #1307454) - For from_is_list feature, use email address from original From: if original From: has no display name and strip domain part from resultant names that
Re: [Mailman-Users] Parallel list question
On 05/03/2014 10:55 AM, Rob Lingelbach wrote: Incidentally, this brings up (what might be considered) a sophomoric question: how to copy a list's config over to a test version of that list, without copying over the member list? Probably a FAQ that I should be aware of... Use Mailman's bin/config_list to dump the list's configuration to a file; edit the file to remove or change list specific things like real_name and maybe subject_prefix, etc, and then use config_list again to apply the settings to the test list. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] new users added to custom MemberAdaptor don't get emails
Mark Sapiro wrote: On 05/02/2014 08:07 AM, Viktor Dick wrote: Hi folks, I have a setup where lists are not open to be joined by anyone but are managed by an LDAP database. The database is queried once an hour and the members of each list are written to a file which is then read in whenever anything is posted to a list. I can't say more about what to do without actually seeing your MemberAdaptor, however you might look at https://bugs.launchpad.net/mailman/+bug/558106 for an alternative. OK, I took a quick look at your stuff from http://sourceforge.net/projects/ldapsync/files/. I think your issue is you rely on extend.py to instantiate FileMemberships and reload the member data when the list is instantiated. I suspect your Mailman is 2.1.14 or older which maintains a list cache in the qrunners so the list gets instantiated and cached and further references to the list object retrieve it from the cache and update it as needed, but it is never again actually instantiated so extend.py is never called again. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
