Mailman 3 June 2014 - Mailman-Developers

[CLI Project] Describe instance and Subscription features
by Rajeev S 16 Jun '14

16 Jun '14

Hi, I have completed the describe instance feature and the subscription features for the CLI. I have pushed the changes as r58.[1] The describe feature is implemented as an extension to the `show` command. This feature adds 3 new usages for the `./mmclient show` action, apart from the previous functionalities. ./mmclient show user foo(a)bar.com [2] ./mmclient show list list1(a)domain.org [3] ./mmclient show domain domain.org [4] The subscription features are built as mentioned in my previous mail ./mmclient subscribe user user1(a)foo.com user2(a)bar.com --list list(a)domain.org ./mmclient unsubscribe user user1(a)foo.com user2(a)bar.com --list list(a)domain.org The commands support usage with either a single user or multiple users. [1] http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision… [2] https://gist.github.com/rajeevs1992/3ca077fd7d1a5a1d5729 [3] https://gist.github.com/rajeevs1992/15f69f5bfdbda52c4e36 [4] https://gist.github.com/rajeevs1992/49fbe250ab9e1f254c11

1 0

GnuPG support
by Stanisław Findeisen 16 Jun '14

16 Jun '14

This thread is a continuation of this one: https://mail.python.org/pipermail/mailman-developers/2011-May/021377.html . Hi What is the current status of this issue? Is there going to be GnuPG support in Mailman 3? -- http://people.eisenbits.com/~stf/ http://www.eisenbits.com/ OpenPGP: 80FC 1824 2EA4 9223 A986 DB4E 934E FEA0 F492 A63B

4 10

Re: [Mailman-Developers] Two more DMARC mitigations
by Stephen J. Turnbull 14 Jun '14

14 Jun '14

Jim Popovitch writes: > On Thu, Jun 12, 2014 at 10:18 AM, John Levine <johnl(a)taugh.com> wrote: > > > * Forwarding signature > > It seems to me that a non-DMARC subdomain, for users, would be easier and > better for all.. No, the mailbox providers already can do that and it's not because they were caught with their shorts down that they didn't. They really really mean "p=reject" for users. A senior admin at Yahoo! was very clear on damrc@ietf that they want their vanilla users covered by "p=reject" because the threat model (which is not phishing, it's "recommended by friend" spam) involves user mailboxes. She also said that (as of a week ago) the attack based on stolen contact lists was continuing to flood their incoming MXes, despite over a month of "p=reject" (contrary to AOL's claims that "p=reject" stopped the attack). No explanation has been given why the spammers are continuing to spend their resources on the attack. > > * Submit and sign > > > > Oh god, NO! Oh, c'mon, Jim. This is just the evil kind of thing we *want* to do to AOL!

3 4

Re: [Mailman-Developers] Two more DMARC mitigations
by Stephen J. Turnbull 13 Jun '14

13 Jun '14

Jim Popovitch writes: > Unless I am mistaking things, the sheer irony here is that Yahoo's > bastardized version of DMARC, which is necessary to stave off > collateral damage from their past security breach(es?), needs to be > further augmented with even less user security in order to be secure. I don't see why the OAuth version of John's proposal would be less secure. If you want real irony, look no farther than Yahoo! Groups' From: header field. Yahoo! is using DMARC to get "yahoo.com" out of the From: field in list traffic, and Groups is putting it right back in.

2 1

Re: [Mailman-Developers] Two more DMARC mitigations
by Stephen J. Turnbull 13 Jun '14

13 Jun '14

Jim Popovitch writes: > > What changed that you object to? > > One of the original __High-Level Goals__ was: > > DMARC is intended to reduce the success of attackers sending > mail pretending to be from a domain they do not control, with > minimal changes to existing mail handling at both senders and > receivers. It is particularly intended to protect transactional > email, as opposed to mail between individuals. Actually, that word wasn't present in Murray's original -00 draft, and was added in two places (along with a definition in terms of "business transactions") in the -01 draft at the same time Ms Zwicky was added as editor, in July '13. :-P According to Chrome's search function, all three uses are still present in the current (April '14) draft (in section 1.2 "Anti-Phishing" and section 2.1 "High-Level Goals" (which contains exactly the text quoted above). Based on what I've seen on dmarc@, the word "transactional" has controversial connotations besides ruling out Yahoo!'s use case. The problem is that Yahoo!'s problem ("acquaintance-recommended spam") is a genuine problem, and could be addressed by DMARC "p=reject" if only Yahoo! users would stop posting to mailing lists. :-) It's not just business uses. Although Elizabeth and I aren't on good terms at the moment because of difference of opinion about Yahoo!'s behavior, I haven't seen anything from her that would indicate that she thinks "p=reject" is a *good* idea ... except that at the moment it's their *only* idea. :-( Steve

1 0

Re: [Mailman-Developers] Two more DMARC mitigations
by Stephen J. Turnbull 13 Jun '14

13 Jun '14

Jim Popovitch writes: > > Do you have specific complaints? > > Yes. Unless it's not already understood... the original idea > behind DMARC centered around non-human transactional emails > (Banking notifications, Facebook status updates, etc.). This was understood, and is why I call what Yahoo! and AOL are doing "abuse". But what is wrong with the spec itself, besides the potential for abuse? > Elizabeth got involved and the spec was morphed (i say bastardized) What changed that you object to? I'm not just nagging, I really want to know. I've been over the spec a couple of times, in a fair amount of detail, and I don't see it. But if there are specific aspects to it that are broken when used as designed, I (and John) may have some input into getting it changed. Murray Kucherawy (the other author of the current Internet-Draft) and Dave Crocker (who's authored more RFCs than the average bear) seem far more on our side than on Yahoo!'s, and there are a couple of other people who have posted intelligent comments (and of course, the usual complement of Net.Kooks without which no standardization effort is complete). Even Elizabeth seems quite reasonable, modulo her job description. John and I are somewhat more likely to have input into auxiliary protocols (such as the DKIM-Delegate protocol that John mentioned) which might make Yahoo!'s use of "p=reject" somewhat more palatable. Steve

2 1

[CLI Project]Developed the describe instance feature
by Rajeev S 13 Jun '14

13 Jun '14

Hi, I have completed the `describe instance` feature for the list object. I herewith attach the sample output of the command. https://gist.github.com/rajeevs1992/3ca077fd7d1a5a1d5729 The describe feature is triggered when the `show` action is supplied a object name of the corresponding domain. ./mmclient show list list1(a)domain.org Further, the CLI can easily be extended to support an independent sub command `describe` to perform the same action, *if necessary*. ./mmclient describe list list1(a)domain.org The describe feature is intended just for getting a snapshot of the object, in one shot. I will be completing the same for rest of the objects and pushing the next revision by 17/06/2014,Tuesday, as I will be away from computer this weekend.

1 0

Re: [Mailman-Developers] Two more DMARC mitigations
by Stephen J. Turnbull 13 Jun '14

13 Jun '14

Jim Popovitch writes: > AND THEN, a (that very same senior admin?) All are the same person I suppose, Elizabeth Zwicky. > Yahoo! employee got involved in the DMARC spec and it became the > bastardized DMARC spec. Do you have specific complaints? I like the DMARC spec as it stands. Yahoo! and AOL are abusing it, in exactly the same way that spammers abuse specs like RFCs 5321 and 5322. And with the same rationale: "because you can't stop us". But that doesn't make it useless, any more than spammers make the fundamental standards for email useless. The informational parts of the protocol are a minor privacy invasion, I guess, but produce very useful data. Even the policy part is useful IMO. You just have to interpret it properly. "p=quarantine" == "p=we-have-a-security- problem-so-don't-trust-unauthenticated-mail-from-our-domain", and "p=reject" == "p=we-have-a-very-serious-security-problem-so- unauthenticated-mail-from-our-domain-is-almost-certainly-a-scam". So tell your Yahoo! users that their mailbox provider has a very serious security problem, and labelled their posts as "almost certain scams."[1] :-) Note that "security problem" here doesn't necessarily mean "security breached". It can also mean "we are a prominent target", as banks and other financial institutions are. Footnotes: [1] I wouldn't be surprised if for those users whose contact lists were stolen 99% of the mail sent under their mailbox is from the spammers. ;-)

2 1

Re: [Mailman-Developers] [Mailman CLI Project] Subscription and Membership related Actions
by Rajeev S 11 Jun '14

11 Jun '14

> > > This is always possible > > subscribe users user1(a)foo.com user2(a)bar.com user3(a)bar.com --list > list(a)domain.org > > Hi, I have built to features, subscribe and unsubscribe users, as described above *subscribe users user1(a)foo.com user2(a)bar.com user3(a)bar.com --list list(a)domain.org* and *unsubscribe users user1(a)foo.com user2(a)bar.com user3(a)bar.com --list list(a)domain.org* The command prints a success message on successful completion of action else prints an error message and continues execution. These feedback messages can be suppressed by using a `--quiet` switch. subscribe users user1(a)foo.com user2(a)bar.com user3(a)bar.com --list list(a)domain.org user1(a)foo.com subscribed to list(a)domain.org user2(a)foo.com subscribed to list(a)domain.org user3(a)foo.com subscribed to list(a)domain.org The commands accept one or more user emails as arguments.

1 0

Users in MM3
by Dick Visser 10 Jun '14

10 Jun '14

Hi I'm looking for a new mailing list manager, and one of the requirements is that it has a web interface, and that it can use SAML authentication. Looking at MM3, I see that there are several options for running the web interface, one of them is Apache & mod_proxy. We already have had positive experiences with mod_mellon (which adds SAML authentication), and another web application (Atlassian Confluence), which sounds like a similar set-up, so I think this could be made to work with MM3 as well. The only issue I'm having is that our current IDM system is build around the concept of identifying users by ID, in our case an integer. My Python knowledge is pretty basic, but from src/mailman/model/user.py it looks like MM3 users are also identified by an id. That would be great, because then Apache with mod_mellon could authenticate a user and populate HTTP headers with the user id, and then MM3 could pick that up. Am I assuming the right things? PS, I'm asking because I've looked at another mailing list manager as well, but that seemed to using the e-mail address as the user identifier, which rendered it useless for us... Thanks!!! -- Dick Visser System & Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands

1 0