Mailman 3 September 2013 - Mailman-Developers

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
by Franck Martin 19 Sep '13

19 Sep '13

When a list goes bad, usually the members are not blamed but the list admin, therefore making the list the system responsible of the writing of the message. Anyhow, it does not matter, this is a religious discussion. Please feel free to code and test your solution of encapsulating the message in a mime rfc822. This seems an interesting and good alternative. I'd like to see it in practice so we can compare data. On Sep 14, 2013, at 1:27 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: > Franck Martin writes: > >> One may argue that since the list is modifying the message, it is >> now the new author of it, this proposal just make it more clearly. > > Nonsense. Here's what RFC 5322 says: > > The "From:" field specifies the author(s) of the message, that is, > the mailbox(es) of the person(s) or system(s) responsible for the > writing of the message. > > The list obviously isn't responsible for the writing of the message > body, and you could argue that in adding header/footer and munging > attachments and Subject field it's acting as the agent of the author, > who is therefore responsible for them too.[1] > > If that's not convincing, ask any of your users if they think "the > list" is an author of their posts, or anybody else's. > > OTOH, if you want to make an authorship claim validly, there's an easy > way to accomplish it: encapsulate the whole thing in message/rfc822. > > Steve > > > > Footnotes: > [1] Note that RFC 5322's phrasing also clearly refutes the same > argument when made for "Reply-To". >

4 6

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
by Franck Martin 18 Sep '13

18 Sep '13

On Sep 17, 2013, at 10:36 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 09/17/2013 10:04 PM, Franck Martin wrote: >> >> 1) If you keep the From: header as it is then, we will still have the same problems > > > Perhaps I wasn't clear. The From: of the outer message would contain the > list address. The From: of its message/rfc822 payload would be unchanged > from that of the incoming message. > > My questions only had to do with the Reply-To: of the outer message in > cases where the list was set to mung Reply-To: in some way. > > Ah, makes sense, sorry >> 2) the purpose of the encapsulation message/rfc822 is not meant to preserve the DKIM signature, DKIM is not meant to be verified by MUAs > > > No, but that is a side effect, at least where content filtering has not > altered the message. Yes indeed

1 0

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
by Franck Martin 15 Sep '13

15 Sep '13

On Sep 14, 2013, at 5:16 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: > Franck Martin writes: > >> Unfortunately z= and especially l= are not used practically by >> senders because they create a risk. One could add an attachment >> containing malware to the message for instance. > > Indeed, we have to assume that the MUAs are broken in this respect. > See Daniel Gillmor's posts on the problems MUAs have with indicating > which parts of a message are signed MIME parts in the "testing MUAs" > thread. > > The basic state of the art seems to be that MUAs can't handle anything > safely except a signature that applies to the whole message. > I'm not sure if DKIM was ever meant to be exposed to the end user, but the current trend is to try to protect the end user as much as possible and this is done best by MTAs than MUAs.

2 1

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
by Franck Martin 15 Sep '13

15 Sep '13

On Sep 13, 2013, at 7:48 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 09/13/2013 12:18 PM, Franck Martin wrote: >> >> Mailman breaks DKIM as soon as you add a footer or tag in the subject line, which a lot of lists do (including this one). > > > Not necessarily. It depends on the DKIM signature and how much of the > body is signed. Granted, you are correct in most cases, but it might be > of interest to some to go to > <https://mail.python.org/pipermail/mailman-developers/2007-February/> > and review the "dkim-signature headers" threads. > Unfortunately z= and especially l= are not used practically by senders because they create a risk. One could add an attachment containing malware to the message for instance. Even cisco does not use them in its signatures anymore. Jim Fenton did a good document on DKIM threats: http://tools.ietf.org/html/rfc4686

2 1

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
by Franck Martin 14 Sep '13

14 Sep '13

One may argue that since the list is modifying the message, it is now the new author of it, this proposal just make it more clearly. In an ideal world, lists should only forward the email, preserving the DKIM signature, but few lists are doing that except the notable exception of apache.org lists. When spam is received from a list (which is rare), the onus is on the list administrator to maintain his/her list content and membership. This option is off by default and at no time it is proposed to change the behavior of any list being in place or upgraded or imported without the list admin consent and action. On Sep 13, 2013, at 12:13 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: > Franck Martin writes: > >> In the upcoming mailman 2.1.16 there has been the introduction of >> the optional feature author_is_list >> >> "Replace the sender > > Before you release, s/sender/author/, please. When discussing > Internet email, sender != author. The name of the feature, "author is > list", is an obvious falsehood: lists don't write posts, they relay > them. These policies do not conform to the email RFCs. (Given the > semantics of "From" set out in RFC 5322, they may even constitute > copyright infringement in the absence of a license from posters > permitting From-munging. But that's not the topic here.) > > AFAICS there's an easy way for Mailman to adapt to DKIM without > violating RFC 5322: wrap every message in a MIME message/rfc822 part > (ie, every message is a one-post "digest"). The wrapper message > obviously can conform to DMARC ("From: LIST@DOMAIN" with appropriate > DKIM signature), and Mailman can DTRT with the wrapped message. > >> with the list address to conform with policies like ADSP and DMARC. >> It replaces the poster's address in the From: header with the list >> address and adds the poster to the Reply-To: header, > > Another RFC violation. :-( What if the poster already set Reply-To > because she *doesn't* want mail at the From address? What if the > list's address *isn't* in Reply-to, but the author expects wide > replies to go to the list? > >> but the anonymous_list > > This is probably OK. > >> and Reply-To: header munging settings below take priority. > > Does this make sense? See above. > >> If setting this to Yes, it is advised to set the MTA to DKIM sign >> all emails. " > > Please change this to "This setting is useful when your host signs > outgoing mail according using DKIM." As written, the advice is > inaccurate anyway. DKIM requires more than just MTA settings. There > must be cooperation from the nameserver. > >> Usage of this feature on lists have indicated no adverse issue for >> the members, > > s/no adverse issue/only minor annoyance/ (I disagree with "minor", but > sure, Outlook users probably won't notice). > > You should remember that "Reply-To munging" works as expected for > almost all subscribers almost all the time on most lists, and for that > reason is widely used despite its ex post obvious deficiencies. When > it fails, though, it's at minimum a minor pain in the ass and at > maximum an inadvertant privacy violation. > > Please go slowly on screwing with From, which (unlike Reply-To) is a > required field and so appears in *every* email and has well-defined > semantics *with which this feature is in deliberate non-conformance*. > >> provided proper communication is done when the feature is enabled >> (as to allow inbox rules to be changed if needed). > > Isn't this a lie? If the From header is corrupt, then there is no > reliable indication of who the author is. If you're lucky you can > fish it out of the body or .signature. Reply-To won't do: not only > are its semantics such that there's no guarantee that it's an alias > for author, but it complicates the rules significantly because you > need different rules for From-corrupting lists and other lists and > non-list mail. > >> In the 2.1.16 Release Candidate the feature author_is_list is >> controlled by the following switches in the mm_cfg.py >> >> ALLOW_AUTHOR_IS_LIST = No >> DEFAULT_AUTHOR_IS_LIST = No >> >> The first one will enable the GUI to present an option to the list >> admin to enable the author_is_list feature, the second controls if >> new lists or upgraded lists should have the author_is_list feature >> set to yes > > "Upgraded" lists? If upgrading to Mailman 2.1.16 causes all my lists > to be corrupted by this feature, I will not be pleased. An option > called DEFAULT should only apply to new lists. > > If you insist on making this a fallback if the list doesn't have an > explicit setting, call the option AUTHOR_IS_LIST. > >> While it is better for the MTA to DKIM sign emails if >> author_is_list is enabled, this is not a requirement and the list >> will work fine without DKIM. > > But why would anybody want to do this in the absence of DKIM? Mailman > already has the RFC 2369 and 2919 fields to tell MUAs that it's a list > post, and a plethora of ways (Subject, header, footer) to tell users > that it's a list post. Anonymous list is already an option for > obscuring the author if that's desirable, and for an announce list > there's no problem, as the list (or an officer of the host) is already > the author. I think you should just delete that sentence. > >> While DEFAULT_AUTHOR_IS_LIST is important to avoid new lists and >> upgraded lists change behavior, setting ALLOW_AUTHOR_IS_LIST to Yes >> does not change how any list is handled (author_is_list in the GUI >> is No by default). it only provides an option to the list admin to >> change the list behavior. >> >> Unfortunately some list admins cannot edit mm_cfg.py (like CPANEL >> type install), therefore it would be nice to remove >> ALLOW_AUTHOR_IS_LIST or set it to Yes by default to let the list >> admin decide how he/she wants the list to behave. Otherwise the >> list admin needs to contact the mailman admin to enable this >> config. > > I'm reluctantly willing to accept a factory default that allows list > owners to decide to systematically violate RFC 5322 (as well as all > predecessors) only if the factory default of DEFAULT_AUTHOR_IS_LIST=No. > >> Please indicates if you are ok to set ALLOW_AUTHOR_IS_LIST to Yes >> or remove this option from mm_cfg.py > > I don't see any obvious loss from removing it, but in keeping with the > general "go slow" attitude toward implementing RFC-violating features, > I think we should keep it for now, but set it to Yes. > > In fact, we SHOULD remove DEFAULT_AUTHOR_IS_LIST. List owners should > make an informed decision to violate RFC 5322, not be defaulted into > doing so. If site owners want to enforce it, let them hack code. > >

2 1

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
by Franck Martin 14 Sep '13

14 Sep '13

----- Original Message ----- > From: "Mark Sapiro" <mark(a)msapiro.net> > To: mailman-developers(a)python.org > Sent: Friday, September 13, 2013 11:31:44 AM > Subject: Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16 > > On 09/13/2013 08:06 AM, Barry Warsaw wrote: > > > > I will leave it to Mark for final decision on this, but my own opinion is > > that > > the mm_cfg.py option should stay. cPanel already customizes their Mailman > > installation, so I think they should set it to Yes when they upgrade their > > systems to 2.1.16. > > > I don't feel strongly about this either way except for the general > principle of least surprise. Enabling this by default has three > downsides that I see. It can render a fully i18n translated General > Options page a bit ugly with one relatively large English paragraph; it > gives list owners yet another bullet with which to shoot themselves in > the foot, and it complicates list configuration by adding yet another > decision. > > None of these is a deal breaker. I researched the i18n issue, and it > turns out only 4 languages currently have a fully translated General > Options page. One of these has already been updated and the other 3 are > being addressed. Most languages already have between 1 and 3 > untranslated strings on this page from prior changes so it could be > argued that one more is not important. > > The other two considerations are relatively minor, but I still lean > towards requiring overt action by the site admin to enable the feature. > > I wanted this brought to mailman-developers in the hope that whatever > discussion ensued would lead to some consensus. > > I confess, I'm not at all up to speed on DMARC. Franck has assured me > that this feature can be useful even in the absence of the DNS and MTA > changes necessary to DKIM sign outgoing list mail, but it seems to me > that enabling author_is_list will almost guarantee that any incoming > DKIM signatures will be broken (the From: is almost certainly included > in the signed headers) which will cause problems if the outgoing mail is > not signed with a valid DKIM signature. > DKIM does not require that the d= to be linked to the domains in the From: that's what DMARC do. Mailman breaks DKIM as soon as you add a footer or tag in the subject line, which a lot of lists do (including this one). The rule with DKIM is to consider any broken DKIM signature as if there was no signature at all. So for instance this list mailman-developers will break all DKIM signatures when resending emails. Mailman could in fact strip DKIM at reception and this would be same effect. So let me explain what author_is_list achieves. if I post to this list using any of these domains which have a p=reject DMARC policy (linkedin.com, paypal.com, twitter.com,...). The original DKIM signature will be broken, and SPF while being valid, will not be aligned, not the same organizational domain as in the From: Return-Path: mailman-developers-bounces+franck=peachymango.org(a)python.org So DMARC will fail, creating the email to be bounced when being resent to members at gmail,yahoo,hotmail,aol,comacast,.. Note: This add to the unsubscription count for these members. With Author is list, the From: becomes (I simplified): From: mailman-developers(a)python.org python.org does not have a DMARC policy, therefore the email will not be bounced due to DMARC for members at gmail,yahoo,hotmail,... For a receiver, the IP is known, the headers contains the List-Id, so what is in the From has not much impact (besides the DMARC check), because it is mainly about the reputation of the sending IP that makes the email delivered to your mailbox. > Also, it seems that an installation would want to validate in some way > incoming mail before taking responsibility, even in a minor way, for > resending it. This would be appreciated, but I'm not sure why adding this extra burden on author_is_list is needed. All installations of mailman should validate somehow messages before resending them, with or without author_is_list. > > All of this leads me to think that making this available to list owners > should be an installation decision rather than being done by default. > I'm not bent on if this option stays in the config file, I find already awesome that the option is present and we (the people using DMARC) have the opportunity to build adoption. Just trying to reduce adoption friction ;)

3 2

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
by Franck Martin 13 Sep '13

13 Sep '13

On Sep 12, 2013, at 11:30 PM, SM <sm(a)resistor.net> wrote: > Hi Franck, > At 22:44 12-09-2013, Franck Martin wrote: >> In the upcoming mailman 2.1.16 there has been the introduction of the optional feature author_is_list >> >> "Replace the sender with the list address to conform with policies like ADSP and DMARC. It replaces the poster's address in the From: header with the list address and adds the poster to the Reply-To: header, but the anonymous_list and Reply-To: header munging settings below take priority. If setting this to Yes, it is advised to set the MTA to DKIM sign all emails. " > > There is an effort (not mailman-related) to mark ADSP as not recommended. > yes I'm aware, it will take a bit of time before the ADSP RFC move to historical status. We are not doing this feature for ADSP...but DMARC. I guess we will drop the word ADSP for 2.1.17 ;)

1 0

Testing different email structures with MUAs
by Abhilash Raj 13 Sep '13

13 Sep '13

Hi, So I was testing which kind of message structure would be the best fit for sending out messages with more than one signature part. I tried 3 things: 1) Message according to [1]this(having two signature parts in a 'multipart/mixed' part inside 'multipart/signed' message. My MUA(*mu4e*[2]) fails to find any signature part at all in this 2) A 'multipart/alternative' message with each part having same structure and each one having different signature. Now although from rfc2046[3] it is not a thumb rule to have different 'content-type' for each alternative part in a 'multipart/alternative', but I think MUAs would get confused if they find both alternative parts completely same(in structure). My MUA shows both parts and thus repeats data. Although it shows two signature parts too. 3) This third type was just my idea, does not follow rfc3156 obviously. I simply added another signature part to the original message and my MUA reads it nicely showing two signatures. I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure. [1]: http://tools.ietf.org/html/draft-ietf-openpgp-multsig-02 [2]: http://www.djcbsoftware.nl/code/mu/mu4e.html [3]: http://tools.ietf.org/html/rfc2046#section-5.1.4 -- Abhilash Raj

4 9

Re: [Mailman-Developers] Send message having same "References" from archive
by Mark Sapiro 05 Sep '13

05 Sep '13

On 08/18/2013 09:20 AM, VuNghia Truong wrote: > > Suppose that I have archive file, like "list_name.mbox". > Now, I want to get the message with same "References" field, and send them > out. > How could I accomplish this problem? from Mailman import Mailbox mid = 'the message Id you're looking for' fp = open('/path/to/list_name.mbox') mb = Mailbox.Mailbox(fp) msgs = [] for msg in mb: refs = msg.get_all('references') for ref in refs: if ref.find(mid) >= 0: msgs.append(msg) break # At this point, msgs contains a list of email.Message.Message objects # that contain 'the message Id you're looking for' in their References: # Sending them is left as an exercise for the reader. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Test: Please ignore
by Patrick Ben Koetter 03 Sep '13

03 Sep '13

Are the mailman footer links HTTPS-Links? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

1 0