Mailman-Developers September 2020

mailman-developers@python.org

5 participants
3 discussions

Verifying broken DKIM signatures
by Alessandro Vesely 28 Sep '20

28 Sep '20

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 15 Sep '20

15 Sep '20

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 07 Sep '20

07 Sep '20

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

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers September 2020