Mailman 3 October 2011 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 08 Nov '22

08 Nov '22

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

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Barry Warsaw 29 Nov '11

29 Nov '11

On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: >There's movement afoot to deprecate use of "X-" in header field names. Just >call it "Mailman-Topic". And if it's worthwhile, consider registering it >with IANA. I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of ones we still add or recognize (some might be used only in the test suite): X-Message-ID-Hash X-Mailman-Rule-Hits X-Mailman-Rule-Misses X-BeenThere X-Mailman-Version X-Mailman-Approved-At X-Archive X-No-Archive X-Ack X-No-Ack X-Peer X-MailFrom X-RcptTo X-Originally-To X-Original-CC X-Original-Content-Transfer-Encoding X-MIME-Version X-Mailman-Copy X-List-Administrivia X-Content-Filtered-By X-Topics X-Mailer X-List-Received-Date X-Approve X-Approved -Barry

10 32

Mailman headers roundup
by Patrick Ben Koetter 16 Nov '11

16 Nov '11

I've created a list to sum up the current discussion/threads on the mailman header work. The list is separated in four sections: I. CLARIFY Needs discussion. II. MODIFY Needs to be registered with IETF or changes X- name. III. KEEP Do not change VI. DELETE Remove from MM3 code Please cross-check and pickup discussion on the CLARIFY items. Once we are done I will approach IETF for the headers that need standardizing. I. CLARIFY X-List-Received-Date This only gets added when the message is sent to the archive. Modify to: List-Archive-Sent Next Step: Discuss X-Message-ID-Hash propose an RFC as an extension of RFC 5064 Modify to: unclear Next Step: Discuss X-Mailman-Version The version of Mailman that sent the message. It can lose the X- prefix. Modify to: List-Agent, Mediator Next Step: Discuss X-Mailman-Approved-At lose the X-prefix Modify to: List-Approved-Date Next Step: Create RFC or Extend RFC 2369? II. MODIFY X-Mailer Only used when Mailman originates messages such as autoresponses. Modify to: User-Agent Next Step: Change code X-Topics This contains a list of all the topic names that matched the message. Are there any other MLMs that support topics in a way that would make that header generally useful? Modify to: Tag Next Step: Create RFC X-Mailman-Rule-Hits They could certainly lose the X- prefix. Modify to: Mailman-Rule-Hits Next Step: Create RFC X-Mailman-Rule-Misses They could certainly lose the X- prefix. Modify to: Mailman-Rule-Misses Next Step: Create RFC X-Content-Filtered-By I think this should be renamed to (X-)Mailman-Content-Filter. Modify to: Mailman-Content-Filter Next Step: Create RFC III. KEEP X-Peer X-MailFrom X-RcptTo Ignore this, it's used in the test suite only. Next Step: Ignore X-Originally-To Probably not worth changing. Next Step: Ignore X-Original-CC X-Original-Content-Transfer-Encoding X-MIME-Version Ignore these. Next Step: Ignore X-Ack X-No-Ack These should keep the X- prefix. Next Step: Ignore X-Approve X-Approved need to keep the above two for backward compatibility Next Step: Ignore VI. DELETE X-Mailman-Copy It can either be removed or lose the X- prefix. Next Step: Remove from code X-BeenThere legacy Next Step: Remove from code X-Archive X-No-Archive deprecated Next Step: Remove from code X-List-Administrivia X-List-Administrivia is just useless and should be removed. Next Step: Remove from code p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563

10 20

Re: [Mailman-Developers] Mailman headers roundup
by Patrick Ben Koetter 01 Nov '11

01 Nov '11

* Murray S. Kucherawy <msk(a)cloudmark.com>: > > -----Original Message----- > > From: mailman-developers-bounces+msk=cloudmark.com(a)python.org [mailto:mailman-developers-bounces+msk=cloudmark.com@python.org] On Behalf Of Patrick Ben Koetter > > Sent: Sunday, October 30, 2011 12:04 PM > > To: Mailman Developers > > Subject: [Mailman-Developers] Mailman headers roundup > > > > I've created a list to sum up the current discussion/threads on the mailman > > header work. > > [...] > > Nice! Thanks. > For the ones that are at "Create RFC", does someone have a specific syntax > they should follow, especially something like ABNF? That plus a description > makes crafting the RFC easy. My impression is we need to settle User-Agent, List-Agent and/or Mediator first. Then, at least that's my plan, I would start to collect/write descriptions, syntax, ABNF etc. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563

2 1

Re: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs)
by Stephen J. Turnbull 29 Oct '11

29 Oct '11

Murray S. Kucherawy writes: > So your perspective is "why bother [distinguishing List-Agent from > User-Agent]", basically? If you put it that way, yes. There sure does need to be a reason to bother. > That's fair, I guess, but at the same time, what's the harm in > making the distinction? Maybe there is no distinction to be made, in which case making an artificial distinction is creating confusion where there was none before. Eg, I can just see someone arguing that when Mailman generates a message (a rejection, a password reminder, whatever) it's a User-Agent, while when it simply relays it's a List-Agent. > If for some reason something down the road wants to indicate the > two separately, this would make it easy. Let that "something" write the RFC, then, when it's got a reason for increasing congestion of the namespace.

1 0

Re: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs)
by Stephen J. Turnbull 29 Oct '11

29 Oct '11

Murray S. Kucherawy writes: > I think having a message with User-Agent and List-Agent is less > confusing than one with two User-Agents. Who's going to be confused? Not end users.[1] I would think the real application is for an administrator or software to look at them and go, "Uh-oh, it's another Outlook|fml|... message" and deal with that agent's peculiarities. As long as there's only one set of foibles associated with Outlook, and another with fml (perhaps not disjoint from Outlook and perhaps associated with several fml-wannabes as well, but consistent across those MLMs that emulate fml), you probably don't need to distinguish -- "MLM" vs. "end-user client" is something (ie, a foible) you can deduce from the agent's name and version string. While I'm not terribly happy with calling an MLM a *user* agent, it's not entirely farfetched, especially in the case of something like Mailman. First, the MLM functions as an agent for the list owner, filtering out evile posts and protecting archives from the eyes of the unwashed. Second, it functions as the agent of each subscriber, avoiding dupes, suspending delivery during vacations, digesting the posts, etc. Footnotes: [1] As the late great George Carlin's alter ego Al Sleet the Hippy Dippy Weatherman put it, "It's 29 degrees at the airport ... which is stupid, 'cause nobody I know lives at the airport." And nobody I know (except me) looks at User-Agent/X-Mailer headers. The-exception-that-proves-the-rule-ly y'rs,

2 1

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Stephen J. Turnbull 26 Oct '11

26 Oct '11

Murray S. Kucherawy writes: > What it says is the list should re-sign if it modifies the message > (or, in general, re-sign anyway). So append whatever you want, > just re-sign the message. Are you insisting that advice is > defective? Defective, maybe not. But I don't think I would follow it for my own lists. I'd rather remove the signature and tell people who are using anal-retentive ISPs that refuse to pass unsigned messages to switch, because there are too many people out there who will report you as a spammer rather than unsubscribe. I don't want my signature associated with any such thing.

2 1

Update on UI development
by Benedict Stein 26 Oct '11

26 Oct '11

Dear Mailman fellows, just a short update in terms of the WebUI - we all know that the targeted release date is now only a little bit more than two weeks to go - @Barry 11.11.2011 is still the target ? Regarding the WebUI development we promissed you to show of at least the results from GSOC this year, but unfortuneatly during some business related time issues we weren't able to do this yet. To be honest - at least for me it's the first day really taking a look at mailman after finishing GSOC, but I'm sure we'll all do our best to get this thing up and running. Florian tries to repair the tests for some tweaks which have been made in a8. And I start working on the UI as well again - at least in the evenings - (South African Time ~ CET) I've heard about one more fellow who wanted to step in - I'm sure we'll find time and place to organize some kind of small meeting - but that's up to Flo :) SUMMARY: Back to work ;)

2 1

Fw: [uds-announce] Design Theater Design sessions at UDS
by Barry Warsaw 26 Oct '11

26 Oct '11

Is there any particular design issue you'd like me to raise for the Mailman 3 web ui or archive ui? There isn't much time to put this together, but I'm willing to do that if there's something worthwhile to have them discuss. If not, I might bring up a MM2 archive issue perhaps. -Barry Begin forwarded message: Date: Tue, 25 Oct 2011 13:42:11 -0300 From: Charline <Charline.poirier(a)Canonical.com> To: uds-announce(a)lists.ubuntu.com Subject: [uds-announce] Design Theater Design sessions at UDS Hello, The design team is planning to run design "theater" sessions at UDS. As a general rule, the design works on Canonical projects. It is our opportunity and pleasure during UDS to dedicate some time to help with other free open source software. * What is Design Theater?* During these sessions, we explore a design issue that you submit to us and take it through our design process. *Why should you come? *We hope to take you through the design process with real life examples, so we can share our design thinking and problem solving with you and propose any solution you might like. *How can you participate? *You have a choice: As an /observer/: come an look over our shoulders as we discuss applications design issues and join in the discussion. As a /participant/: bring us your free software application for which you need design guidance or user experience input. We'll try to fix it for you and show you how to approach this particular problem the design way. If you are thinking of joining us as a participant, please, send us your design question in advance, if you can, so we can get the ball rolling. Send it to: charline.poirier@canonical .com *Who will be there from the Design team? *At each session, you will find a user researcher, a brand designer, a user experience specialist, an interaction designer and a visual designer, *Come find about our process and challenge us!* -- *CHARLINE POIRIER* *Acting Head of Design* *Canonical* *27th floor, 21-24 Millbank Tower* *London SW1P 4QP UK* *Tel: +44 (0) 20 7630 2491* *Mob: +44 (0) 78 8695 4514* *www.Ubuntu.com <http://www.Ubuntu.com/> <http://www.Ubuntu.com/>* *www.Canonical.com<http://www.Canonical.com/>* -- uds-announce mailing list uds-announce(a)lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/uds-announce

2 1

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Richard Damon 25 Oct '11

25 Oct '11

On 10/25/11 6:00 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Stephen J. Turnbull [mailto:stephen@xemacs.org] >> Sent: Tuesday, October 25, 2011 2:50 AM >> To: Murray S. Kucherawy >> Cc: mailman-developers(a)python.org >> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs >> >> I agree, and have no objection to advocacy, or to RFCs that take >> advantage of more modern thinking. But that's very different from >> arguing that a defect in the DKIM RFC is really a problem of the >> implementations. > Well, I also don't agree with characterizing this as a defect in the DKIM RFC. > I would consider an RFC that tells some people they need to violate the laws of their country to follow it to have a defect. Their are places, like Germany has been mentioned, where bulk mailers, like Mailing Lists, need to place in a prominent place unsubscription instructions. It is a fact, that in the current state of software, the LIST-UNSUBSCRIBE header is not likely to be seen by a typical user. Therefore, the only legal place to put the required notice is in the body of the message. Now, if 90+% of people would see the LIST-UNSUBSCRIBE header someone might be able to make a case that the few who didn't should have been able to see it, but with Current MUAs it isn't seen. I suspect that (way) less than 10% of people would see the LIST-UNSUBSCRIBE header unless they went looking for it. Is there even an MUA that by default will show it? How many people have MUAs that can even be easily configured to show this header and not all headers? I can think of a few that can be configured to add arbitrary headers to the default show list, but these are not the ones used by most people, but I am not sure if I can think of one that knows about this header so you can add it without having to personally know about it.

2 1