Mailman 3 September 2020 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Verifying broken DKIM signatures
by Alessandro Vesely Sept. 28, 2020

Sept. 28, 2020

Hi all, there's been quite some discussion about signature breaking in indirect mail flows. Rewriting the From: header field seems to be the most popular workaround. Yet, it is possible to undo the transformation that Mailman put in place, thereby validating the original DKIM signature. I have a few questions about this. That technique is described by the DKIM Transformations draft[*]. It considers a number of reversible transformations, such as adding a footer or adding a mime part containing a footer. I implemented a utility to carry out that task, and it works in a good deal of cases. However, it fails in some cases. Mailman carries out some irreversible changes, such as rewriting To: or Cc: changing the order of the mailboxes, or rewriting Content-Transfer-Encoding: irrespective of quotation marks and case (for example "7bit" even if the original, signed field was spelled as "7Bit"). I guess this behavior is coded deeply in Python libraries, but would like to know developers' opinions. Is that something that could be fixed? The second question is about producing a hint to the verifier telling which transformation(s) have been applied to the message. That would come as an additional header field, for example: DKIM-Transform: footer or as an extra tag in a DKIM signature, for example: DKIM-Signature: v=1; (...) tf=footer; (...) That hint could spare the verifier one pass over the message. Is it something that could be implemented? If not, I'd try guessing, according to this scheme: outermost Content-Type: | first entity Content-Type: | transformation | ------------------------+-----------------------------+-----------------+ text/plain | any | footer | ------------------------+-----------------------------+-----------------+ multipart/mixed | multipart/mixed | add-part | ------------------------+-----------------------------+-----------------+ multipart/mixed + any other | mime-wrap | ------------------------+-----------------------------+-----------------+ any other | any | non-reversible | ------------------------+-----------------------------+-----------------+ Does that look correct? I know that Mailman has many more features that can hardly be amenable to a fixed set of easily reversible transformations. The point is to be able to preserve DMARC for /some/ mailing lists which care to do so. Currently, there are mailing lists which don't do any change, not even subject tags, in order to avoid breaking DKIM signatures. A somewhat Procrustean solution. I don't think From: rewriting is going to be disabled any time soon. Of course, the original From: must be known in order to validate the original signature. In this respect, I'm hesitant about using Reply-To:. I read in the wiki the original content of From: /may/ be added to Reply-To: or to Cc:. In addition, Reply-To: usually comes after From:, thereby requiring to go back to change already parsed fields. As an alternative, I'd provide for yet another field to be put near the top of the header. Original-From:, say. This may seem redundant, however it serves a different goal. In addition, if the Original-From: is put in place by the original signer, it ratifies its knowledge that From: will be rewritten and its willingness to recover it afterwards. Is this endeavor completely useless, given that the current settings work well enough? Or could it help keeping a consistent DMARC semantics among participants yearning to do so? I'd be glad to hear your opinions... Best Ale -- [*] https://tools.ietf.org/html/draft-kucherawy-dkim-transform

2 3

Anonymous mailing lists
by vesely＠tana.it Sept. 15, 2020

Sept. 15, 2020

Someone started talking about the risk of having their names and email addresses archived in a publicly accessible mailing list. So I thought I'd ask. In short, the proposal provided for completely removing such data, to protect privacy. See here for more: https://mailarchive.ietf.org/arch/msg/dmarc/fEi0-1NFP-rkrx70Ne1t7fPzldA (There are more threads there mentioning Mailman, in case your ears are burning.) As an additional bonus, that would also "solve" any DMARC problem. Is there a FAQ entry for this? Best Ale

4 5

Using hyperkitty_import for archives downloaded from HK
by goran.terzic＠gmail.com Sept. 7, 2020

Sept. 7, 2020

I noticed that hyperkitty_import has issues with In-Reply-To header when importing archives downloaded from Hyperkitty itself. In some cases in_reply_to field in hyperkitty_email table will have extra white space at the start. For example In-Reply-To: CAFV2YWOfZRHEDTTz3F6Emnwx8Sh4_Ar7+JMR7XvOAD8_eOjqaQ(a)mail.gmail.com will be saved as ' CAFV2YWOfZRHEDTTz3F6Emnwx8Sh4_Ar7+JMR7XvOAD8_eOjqaQ'. This results in broken threads, as parent of this message cannot be found. I also noticed that hyperkitty_import doesn't have this problem with archives from MM2, but in MM2 archives, message id in in-reply-to header is surrounded with brackets, like this: In-Reply-To: <CAFV2YWOfZRHEDTTz3F6Emnwx8Sh4_Ar7+JMR7XvOAD8_eOjqaQ(a)mail.gmail.com> When I look at original email source, in-reply-to header doesn't have brackets; it looks like in the archive made by HK. Is the issue here with import or export (download) process? Is hyperkitty_import right tool for migrating lists from one MM3 server to another? I was thinking should I post this to the mm3-users list or here, I hope I made a right decision. Regards, Goran T.

3 4