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
> 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?
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.
> 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?
The next set of tasks for the coming weeks, before the mid term
evaluation, are mostly subscription and membership related actions for the
The various actions that are to be implemented are
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
show-members list list(a)domain.org
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
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
Edit/Set list settings
List preferences can be set or modified using
edit list list(a)domain.org –key KEY –value VALUE
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
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`
subscribed lists, with role
Details available for domain
Details available for object list
The above details can be displayed in groups, with appropriate group
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.
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.
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.
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
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?
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
The refactoring mainly includes imposing the of DRY principle -- moving
to the lib/* directory.
As an end note, this is a hefty revision. :)