[Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update
On Fri, Jun 4, 2010 at 22:43, Mark Sapiro m...@msapiro.net wrote: Ian Eiloart wrote: Well, maybe, but I've had to switch on approval for various lists because of subscribing spammers. As Barry suggests, setting moderation of new members as the default can also thwart the subscribing spammers. A smart spammer would hardly post to the mailing list --atleast on linux lists its asking to be moderated or kicked out, depending on the admins. I've checked out spammers who mass subscribe to the lists at Debian, Ubuntu, Fedora and RH, to access the email id's of all the subscribers (if this is set as available only to the list members). If the settings are membership list is available only to the *-owner, the spammer can still subscribe, and lurk on the list to silently harvest the email id's of all the folks who post mails to any list they lurk on. The latter can be identified by checking their TLD when they sub to the list but if they use *-free-email-provider like a gmail or yahoo address to sub and lurk, its hard to tell. -- thanks and regards, vid || http://svaksha.com ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] spammers harvesting email ids
स्वक्ष wrote: I've checked out spammers who mass subscribe to the lists at Debian, Ubuntu, Fedora and RH, to access the email id's of all the subscribers (if this is set as available only to the list members). This is pointless, as you can harvest contributors' email addresses from web-based archives for most of these lists even without being a subscriber: http://lists.debian.org/debian-user/2010/06/msg0.html -Julian signature.asc Description: This is a digitally signed message part. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Fri, 4 Jun 2010, Anna Granudd wrote: there are some mock-ups on the wiki (see http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you could help with ideas for a nice design and layout! As a blind person, I'm not able to comment on these as these are images. I can understand the desire for an overhall of the Mailman UI, but I think it's worth saying that for the most part, the 2.x UI works well for people using screen reader technology. The only area which provides some challenges is the membership management screen, as it can be difficult to associate each checkbox with the function it performs. But even this can be managed using screen reader commands for reading tables. I realise that Mailman 3.x will make it possible to create multiple UIs, as the functionality will be separated from the UI. However, it is also my experience that alternate/specialised UIs can and do go unmaintained, and as such it is my hope that the (or at least a) standard UI shipped by default with Mailman will provide the needed accessibility. So this is one of the reasons why I'm on this list, to keep an eye on developments and hopefully provide some feedback when a test server becomes available. Right now, my UI wishlist is as follows: 1. At least one UI with no *necessary* javascript. Maybe this won't be the main UI, but as a person who uses the Linux console with a text-mode browser, I like the fact that I can quickly fire up my browser to deal with a moderator request with no fuss. Given that a package like Squirrelmail can operate completely without Javascript if the user chooses, this should surely be possible. 2. Proper use of the label tag in association with form elements. This was (or seemed to be done) fairly well for the most part, with the exception of those checkboxes I mentioned, but I'd hate to see this lost. What this means in practice is that screen readers will read the appropriate label text when focusing upon a form element. There's probably other important stuff, but this is all that comes to mind right now. Other non-accessibility-related things which I think are worth considering are: 1. More useful archives with search capability. I'm sure this is on a dozen wishlists. 2. A friendlier front page per list. Surely having 3 forms on the front page (or is it 4?) is a bit intimidating to some. I've got some other feature requests based on 2.1.x functionality but I'll post that somewhere else more appropriate. Geoff. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
At 07:29 AM 6/3/2010, Anna Granudd wrote: Hi, my name is Anna and I'm participating in GSoC for Systers where my project this summer is to develop a new UI for Mailman 3.0 as well as a UI extension for Systers who are running a customized version of Mailman. The UI will be written as an app in Django. Together with my mentor Florian we've discussed some general matters regarding the UI and the most recent concern adding a database for it. We figured it might be good to use the core db only for the standard UI with which we'll communicate through the rest-client and for organizations wishing to customize the UI, such as Systers, we'll let them add a UI db. Other things we've discussed was the number of apps for the UI, if we should use only one or if we should separate it into, for instance, one app for the user UI's and one for the admin UI, or possibly split it up even more. We've gathered all our thoughts on http://wiki.list.org/display/DEV/Web+Interface+Status and now we'd like to get some feedback from you people as well as to find out if you have other opinions or ideas for us. I/we would really appreciate your help on this. I hope that you plan on following WCAG 2.0 standards! There are plenty of moderators and Admins who are blind or have other disabilities and still want to keep using the software! Dave ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Geoff, I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. This said: I believe the current interface is too complicated even for those who don't need to meet any perceptional or motional challenges: - It doesn't enforce reasonable grouping of related functions - It exposes an immense number of configuration options to the user but doesn't seem to prioritize how often they are required - It has a high signal noise ratio i.e. it's crowed with text (help messages) which makes it hard to focus on the configuration options themselves. - HTML is not used in a semantic way. You already mentioned there's no association between option names and their fields aka 'labels'. If I remember correctly structure i.e. headings and reasonable use of list are also missing. The list is totally uncomplete, but I guess you get the idea. This and more should go and be replaced by better solutions AND the interface should be modern, nice to look at and provide a set of comfortable JavaScript functions. But JavaScript et al. must not be a basic requirement. We want progressive enhancement http://en.wikipedia.org/wiki/Progressive_Enhancement and, to answer one of your questions in your message, our goal is to ship a default user interface that provides the needed accessibility. You mentioned some other feature requests based on 2.1.x functionality. I'd be curious to learn what they are and even more than that I would like to invite you to help us create a user interface that works for as many as possible. p...@rick * Geoff Shang ge...@quitelikely.com: On Fri, 4 Jun 2010, Anna Granudd wrote: there are some mock-ups on the wiki (see http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you could help with ideas for a nice design and layout! As a blind person, I'm not able to comment on these as these are images. I can understand the desire for an overhall of the Mailman UI, but I think it's worth saying that for the most part, the 2.x UI works well for people using screen reader technology. The only area which provides some challenges is the membership management screen, as it can be difficult to associate each checkbox with the function it performs. But even this can be managed using screen reader commands for reading tables. I realise that Mailman 3.x will make it possible to create multiple UIs, as the functionality will be separated from the UI. However, it is also my experience that alternate/specialised UIs can and do go unmaintained, and as such it is my hope that the (or at least a) standard UI shipped by default with Mailman will provide the needed accessibility. So this is one of the reasons why I'm on this list, to keep an eye on developments and hopefully provide some feedback when a test server becomes available. Right now, my UI wishlist is as follows: 1. At least one UI with no *necessary* javascript. Maybe this won't be the main UI, but as a person who uses the Linux console with a text-mode browser, I like the fact that I can quickly fire up my browser to deal with a moderator request with no fuss. Given that a package like Squirrelmail can operate completely without Javascript if the user chooses, this should surely be possible. 2. Proper use of the label tag in association with form elements. This was (or seemed to be done) fairly well for the most part, with the exception of those checkboxes I mentioned, but I'd hate to see this lost. What this means in practice is that screen readers will read the appropriate label text when focusing upon a form element. There's probably other important stuff, but this is all that comes to mind right now. Other non-accessibility-related things which I think are worth considering are: 1. More useful archives with search capability. I'm sure this is on a dozen wishlists. 2. A friendlier front page per list. Surely having 3 forms on the front page (or is it 4?) is a bit intimidating to some. I've got some other feature requests based on 2.1.x functionality but I'll post that somewhere else more appropriate. Geoff. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind.de Security Policy: http://wiki.list.org/x/QIA9 -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht
