Mailman 3 April 2010 - Mailman-coders

[Bug 266631] Re: remove user from all lists
by speeves 08 Apr '10

08 Apr '10

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 07 Apr '10

07 Apr '10

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 07 Apr '10

07 Apr '10

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 05 Apr '10

05 Apr '10

** 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