Mailman-Developers September 2020

mailman-developers@python.org

5 participants
3 discussions

by Alessandro Vesely

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

5 months

Anonymous mailing lists

by vesely＠tana.it

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

5 months, 2 weeks

Using hyperkitty_import for archives downloaded from HK

by goran.terzic＠gmail.com

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.

5 months, 3 weeks

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