Mailman 3 June 2014 - Mailman-Developers

Re: [Mailman-Developers] Thinking about list footers
by Stephen J. Turnbull 10 Jun '14

10 Jun '14

Murray S. Kucherawy writes: > On Wed, Jun 4, 2014 at 8:39 AM, Stephen J. Turnbull <stephen(a)xemacs.org> > wrote: > > > If I understand you correctly, we actually already have the mechanics > > for this in place. Most sites like Yahoo! allow you to whitelist a > > sender. "You" here is the individual Yahoo! user. The whitelists are per-user. > If that's the case, you still have the scaling problem of populating the > whitelist. How would Yahoo! go about doing that, for example? They claim > at least 30,000 such cases that ideally would land in that list > automatically somehow. It's not "the" whitelist, it's all the users' personal whitelists. I don't know if Yahoo! offers such whitelist capability, or if they simply use some heuristic based on the users' contact list, or what.

1 0

Re: [Mailman-Developers] Thinking about list footers
by Stephen J. Turnbull 09 Jun '14

09 Jun '14

Murray S. Kucherawy writes: > We didn't intend for this to be used by MUAs, however, so to some degree > they're doing what we expected. I know, but I think it's time for the IETF to recognize that email fraud cannot be fought if the receiving end of "end-to-end" doesn't go all the way through the eyeballs, optic nerve, and into the wetware. (Maybe we need an April 1 RFC for neural transport of IP packets first?) > I'm trying to figure out if that would be useful at all, but it > sounds like MUAs are the showstopper there. I sure don't want to give up! Some huge fraction of users must use GMail, Yahoo! mail, AOL, Hotmail, or Outlook for their MUAs. And that should cover the vast majority of "Most Likely to Fall for a Phishing Attack" users. Not that "vast majority" is anything to write home to mother about, but it's a very good start. With Comcast and a couple of others taking potshots at Yahoo!, I'd think the big ESPs are probably ready to take MUA improvement seriously. (Starting with protecting addressbooks, of course, but HCI stuff too I hope.) Where is Dave Hayes when we so desperately need his AI newsreader? Steve

3 4

Re: [Mailman-Developers] [Mailman CLI Project] Subscription and Membership related Actions
by Abhilash Raj 09 Jun '14

09 Jun '14

Hi Rajeev, On Fri, 6 Jun 2014 15:54:03 +0530 Rajeev S <rajeevs1992(a)gmail.com> wrote: > The `list members of a list` feature is currently available as a part of > the users module, that takes list name as an argument. > > > show user –list list(a)domain.org > > > This does not print the names of the list owners and moderators who are > not members of the list by default. They can be added to the list by > appending the `list.owners` and `list.moderators` to the member list. Is > there a necessity of a new command under the `list` scope that does the > same function? > > > show-members list list(a)domain.org I think it would be more intuitive to have this command in list scope rather than user scope. And anyway list scope must have a command to list all subscribers. > 1. > > Subscribe/Unsubscribe users from a list > > The commands suitably belongs to the user scope > > > subscribe user foo(a)bar.com –list list(a)domain.org > > unsubscribe user foo(a)bar.com –list list(a)domain.org Could it be used somehow to subscribe or unsubscribe more than one user? If it was like `subscribe list list(a)domain.org --user/users user1/user1,user2,user3`. Or maybe some other way to do it in user scope itself? -- thanks, Abhilash Raj

2 1

[Mailman CLI Project] Subscription and Membership related Actions
by Rajeev S 06 Jun '14

06 Jun '14

Hi, The next set of tasks for the coming weeks, before the mid term evaluation, are mostly subscription and membership related actions for the CLI. The various actions that are to be implemented are 1. Show members of a list The `list members of a list` feature is currently available as a part of the users module, that takes list name as an argument. show user –list list(a)domain.org This does not print the names of the list owners and moderators who are not members of the list by default. They can be added to the list by appending the `list.owners` and `list.moderators` to the member list. Is there a necessity of a new command under the `list` scope that does the same function? show-members list list(a)domain.org 1. Subscribe/Unsubscribe users from a list The commands suitably belongs to the user scope subscribe user foo(a)bar.com –list list(a)domain.org unsubscribe user foo(a)bar.com –list list(a)domain.org 1. Add/remove owners/moderators These commands come under the list scope add-owner list list(a)domain.org –user a(a)b.com remove-owner list list(a)domain.org –user a(a)b.com add-moderator list list(a)domain.org –user a(a)b.com remove-moderator list list(a)domain.org –user a@b. <a(a)b.com>com and a pair of commands to list the owners and moderators show-moderators list list(a)domain.org show-owners list list(a)domain.org 1. Edit/Set list settings List preferences can be set or modified using edit list list(a)domain.org –key KEY –value VALUE 1. Setting membership preferences set preference –key KEY –value VALUE Discussions on placing a `domain` attribute to this command have been done, but I doubt whether a decision was made. I list below a possible usage set preference –key KEY --value VALUE [--global/--user USER /--address ADDRESS] 1. Describe instance Describe instance can be used to display the details of an instance, like settings and preferences. This can be achieved by extending the `show` command of each instance, by passing a key to the specific instance, like show list list(a)domain.org show user foo(a)bar.com show domain domain.org The details available for the object `user` addresses created_on display_name preferences self_link subscribed lists, with role user id Details available for domain base_url contact_address description show lists mail_host url_host Details available for object list list_id list_name mail host members moderators owners pending requests settings The above details can be displayed in groups, with appropriate group headings. BTW,I have pushed the r57 that adds the unit tests for the `lists`. The unit tests for the `users` will be a part of the next revision, r58. Apart from that, I would like to add the `describe instance`, `subscribe/unsubscribe' features for the r58.

1 0

Thinking about list footers
by Stephen J. Turnbull 03 Jun '14

03 Jun '14

Murray S. Kucherawy writes: > What's the expertise on the idea of adding footers in a new MIME text/plain > part rather than just bolting it onto the text as-is? (Or is that already > done?) What do MUAs generally do with multipart text/plain bodies? As Mark and Barry point out, the MUAs-for-people-most-vulnerable-to- email-fraud often handle them poorly. Also, the last time partial signatures came up, it was pointed out that there are *no* MUAs that differentiate between signed parts and unsigned parts. You don't get a warning when your eyes move from a signed part to an unsigned part or vice-versa the way you do when following a link from an HTTP URL to an HTTPS URL in a browser. The DKIM advocates have not liked the idea of signatures that don't apply to the whole message at all. > And along those lines, do any MUAs do useful things with the > various List-* fields, other than permitting one to sort on them? I think many do. I had a proposal some years back that I discussed with the Mozilla people. The idea was to devise an algorithm for MUAs that would get rid of Reply-To munging in most cases, and an optional header field that would allow lists to express a preference. They thought it would be nice if someone would write up a document but weren't much interested in helping or implementing, they thought their products already did a good job. There were some refinements but the basic idea was 1. If there is a Reply-To:, use that address, otherwise 2. if there is a List-Post:, use that address, otherwise, 3. reply to the address in From:. The optional field (I even forget the name, it was something like List-Prefer-Reply) allowed giving From: priority over List-Post:. I'm pretty sure that Thunderbird, Mutt, and Emacs/Gnus implement either a "smart" reply algorithm or or a reply-to-list function. Other Emacs-based MUAs probably do, and it would be trivial to add in most cases. I don't know about KMail, Sylpheed, and Evolution. On the other hand Windows and web-based MUAs didn't do much useful at the time, and probably don't now, either.

2 1

Re: [Mailman-Developers] [CLI Project] Introduced Unit tests to CLI
by Barry Warsaw 02 Jun '14

02 Jun '14

On Jun 02, 2014, at 12:56 PM, Rajeev S wrote: >I was in an idea to follow "the one class per file" style, especially when >the classes tend to grow large in size as in the tests.(It was mentioned in >the Barry's style guide, and so is a common coding guideline.) > >Should I change that? I intend to relax this constraint, whenever I get back to updating the style guide. In the meantime, don't consider the one-class-per-module a hard and fast rule, especially for test modules. Use your best judgment and when in doubt, defer to readability, navigation, and discoverability. Cheers, -Barry

1 0

Moderating subscriptions
by Aurelien Bompard 02 Jun '14

02 Jun '14

Hey y'all, In Mailman 3, I'm trying to create a list that would require its moderators to approve subscriptions. In the Mailman doc, this is commonly referred to as a "closed" list. However, I can't find a way to create such a list, nor the database field which would mark it as such. I've also seen the hold_subscription() function in app.moderator which seems to handle subscriptions that require moderation, but this function does not seem to be used anywhere. It feels like I'm missing a piece of the puzzle here, could somebody point me to it? Thanks! Aurélien

1 0

[CLI Project] Introduced Unit tests to CLI
by Rajeev S 02 Jun '14

02 Jun '14

Hi, As per Abhilash's comment to follow the TDD, I have covered the test cases for the `domain` scope. I know that TDD requires to write tests before implementation. However, I believe that it's not a good idea to postpone test cases for the existing units further. Also, I would like to thank Abhilash for the comment, before its too late to begin writing the tests. I have pushed the r56 that includes the test scripts. I have also done some significant refactoring on the code this weekend, to facilitate easy usage with the unittest package and to make the code more cleaner. The refactoring mainly includes imposing the of DRY principle -- moving repetitive code to the lib/* directory. As an end note, this is a hefty revision. :) http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision… Thank You!

2 2