Mailman 3 April 2010 - Mailman-coders

[Bug 558249] Re: Host based langage selection
by Julian Edwards April 12, 2010

April 12, 2010

** Branch linked: lp:~mvo/launchpad/support-timeframe-kubuntu -- Host based langage selection https://bugs.launchpad.net/bugs/558249 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 266554] Re: Integration of Mailman and htdig for archiving
by Mark Sapiro April 9, 2010

April 9, 2010

It's not a bug, it's a patch, and it's still relevant. ** Changed in: mailman Status: Invalid => Confirmed -- Integration of Mailman and htdig for archiving https://bugs.launchpad.net/bugs/266554 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 266553] Re: Archive indexer control to improve index
by Mark Sapiro April 9, 2010

April 9, 2010

It's not a bug, it's a patch, and it's still relevant. ** Changed in: mailman Status: Invalid => Confirmed -- Archive indexer control to improve index https://bugs.launchpad.net/bugs/266553 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 558106] Re: A MemberAdaptor for LDAP-based membership
by Mark Sapiro April 8, 2010

April 8, 2010

This update (0.6) from Chris Nulk adds additional fields from LDAP givenname - givenname/firstname typically, preferredname - preferred name instead of givenname, sn - surname/lastname, fullname - usually first/given name and last/sur name combined, to be consulted in defining the member's real name. ** Attachment added: "LDAP MemberAdaptor, v 0.6" http://launchpadlibrarian.net/43477175/LDAP_Memberships.py -- A MemberAdaptor for LDAP-based membership https://bugs.launchpad.net/bugs/558106 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 558106] Re: A MemberAdaptor for LDAP-based membership
by Mark Sapiro April 8, 2010

April 8, 2010

This version (0.5) of LDAPMemberships.py supports mixed case email addresses and properly returns None from the getMemberName method if the member has no 'cn' value in the LDAP database. ** Attachment added: "LDAP MemberAdaptor" http://launchpadlibrarian.net/43476506/LDAPMemberships.py -- A MemberAdaptor for LDAP-based membership https://bugs.launchpad.net/bugs/558106 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 266631] Re: remove user from all lists
by speeves April 8, 2010

April 8, 2010

As of: ii mailman 1:2.1.11-11 Powerful, web-based mailing list manager There is a --fromall flag, which removes the user from all lists on the server: remove_members --fromall addr1 --fromall Removes the given addresses from all the lists on this system regardless of virtual domains if you have any. This option cannot be used -a/--all. Also, you should not specify a listname when using this option. ** Changed in: mailman Status: Invalid => Fix Released -- remove user from all lists https://bugs.launchpad.net/bugs/266631 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 557493] [NEW] Mailman must not strip DKIM-Signature headers
by James Ralston April 7, 2010

April 7, 2010

Public bug reported: I reviewed the discussion that led to the decision to have Mailman strip DomainKey-Signature and DKIM-Signature headers: http://mail.python.org/pipermail/mailman- developers/2006-January/018537.html This may have been the correct action to take in 2006. But since then, the DKIM standard has been finalized (RFC4871), and it contains: 3.5. The DKIM-Signature Header Field The DKIM-Signature header field SHOULD be treated as though it were a trace header field as defined in Section 3.6 of [RFC2822], and hence SHOULD NOT be reordered and SHOULD be prepended to the message. RFC2822 defers to RFC2821, which has been replaced by RFC5321, which states: 4.4. Trace Information An Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location. Ergo, Mailman MUST NOT strip DKIM-Signature headers. Even if Mailman knows that actions it will take with the message will invalidate one or more DKIM-Signature headers, those (now-invalid) signatures MUST be left intact. DKIM-Signature headers must be treated exactly like trace (Received) headers. This isn't simply a case of doing the right thing just for standards compliance: although DKIM states that MTAs can't treat the lack of a DKIM signature any differently than an invalid DKIM signature, the presence of a DKIM-Signature header (even invalid) is a consumable item for MUAs; e.g., a token for Bayesian anti-spam systems. (For example, we currently receive *zero* spam with forged DKIM-Signature headers for our own domain. Zero. Thus, even an invalid DKIM-Signature header is incredibly useful to have.) The fix for this is simple; just remove this line from Mailman/Handlers/CleanseDKIM.py: del msg['dkim-signature'] As for DomainKeys, although the DomainKeys protocol is now historical, RFC4870 states: 3.5.2. Determining Whether an Email Should Be Signed A signer MUST NOT sign an email that already contains a "DomainKey- Signature:" header unless a "Sender:" header has been added that was not included in the original signature. The most obvious case where this occurs is with mailing lists. A signer SHOULD NOT remove an existing "DomainKey-Signature:" header. The difficulty here is that the signer (downstream from Mailman) cannot guarantee that a Sender header was added that was not included in the original signature, but it is forbidden from adding another DomainKey- Signature header if that wasn't the case. I suspect this is why many (most?) DomainKeys signers simply refrain from signing if a DomainKey- Signature header is already present, which is the behavior that Joe Peterson observed, and led to the decision to unconditionally strip all DomainKey-Signature and DKIM-Signature headers. Thus, I think Mailman stripping DomainKey-Signature headers is probably still the best choice; leaving them will all but guarantee that any downstream DomainKey-signer will refrain from generating a DomainKey- Signature. This isn't optimal, of course, but implementation ambiguities like this are why DomainKeys is now historical. But Mailman absolutely needs to cease stripping DKIM-Signature headers. (And really, CleanseDKIM.py should be renamed to CleanseDomainKeys.py.) ** Affects: mailman Importance: Undecided Status: New -- Mailman must not strip DKIM-Signature headers https://bugs.launchpad.net/bugs/557493 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

2 1

[Bug 266630] Re: Search Archives
by Jan-Christoph Borchardt April 7, 2010

April 7, 2010

This is still valid because there still is no search function. I just wanted to use one but could not. ** Changed in: mailman Status: Invalid => Confirmed ** Summary changed: - Search Archives + there is no search function for archives -- there is no search function for archives https://bugs.launchpad.net/bugs/266630 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 294223] Re: Bugs missing after import from SourceForge
by Graham Binns April 5, 2010

April 5, 2010

** Project changed: mailman => malone ** Changed in: malone Status: New => In Progress ** Changed in: malone Assignee: (unassigned) => Graham Binns (gmb) -- Bugs missing after import from SourceForge https://bugs.launchpad.net/bugs/294223 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0