Re: [Mailman-Users] Suggestion: Add a new binary flag: "Discard [or bounce] Sender Posts

[Mark Sapiro]

On 04/17/2017 03:00 AM, Julian H. Stacey wrote:
> 
> Summary:
> In eg http://mailman.berklix.org/mailman/admin/test/members/list
> next to column "mod" there would be a 2nd column eg "self discard".
> - "mod" would as before be set by admin to block & store for review.

Or reject or discard based on member_moderation_action.


> - "self discard" would discard posts from member, set by member.


And presumably, unlike mod, this would also be exposed on the user's
options page.

In any case, thanks for the suggestion, but even if you submitted an
implementation, this would not be implemented in MM 2.1. I don't see
sufficient interest in this feature to justify implementing it in MM
2.1, and adding it to the list of features that need to be forward
ported to MM 3.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Suggestion: Add a new binary flag: "Discard [or bounce] Sender Posts

[Julian H. Stacey]

Top posting is bad. 
Failing to indent prior text with "> " is bad.
Corrected below:

Gretchen R Beck wrote:
> Julian H. Stacey wrote:
> > Hi mailman-users@python.org
> > Suggestion: Add a new binary flag: "Discard [or bounce] Posts From Sender
> > http://berklix.org/~jhs/help/majordomo/#discard_sender
> > 
> > Reason: A mailman list member got his address book harvested by a spammer,
> > twice spammed a mailman list I run, I removed list member, asked
> > member to rejoin with an address spammer did not know was subscribed
> > to list.  Another list member suggested I could instead personaly
> > moderate all future mail from the spammer harvested address.
> > http://berklix.org/~jhs/help/majordomo/#harvested
> > 
> > PS (ignore "majordomo" in URLs, I just havent moved text yet.)

> Couldn't you just do individuals subscribers  as a spam filter within the 
> Privacy options?

No.

- There's no automatic individual linkage between eg
http://mailman.berklix.org/mailman/admin/test/privacy/spam
  & list member entries in eg
http://mailman.berklix.org/mailman/admin/test/members

- Privacy options are controlled by admin, not list members.
  For multiple reasons in 
http://berklix.org/~jhs/help/majordomo/#harvested
  the intent is to Avoid burdening admins to waste time for indivduals,
  turning their discard bits off & on.

- Intent is to empower members to disable & enable their personal discard
  options when they choose (perhaps just enabling for a few minutes if they
  normaly just read a list & rarely have something to post) .

  Those who still continued to emit spam could be removed as before, 
  but admin would also instead have the extra option of enabling
  list member's Enable Transmit Discard, & it would be in the right
  place where list member could personaly, without admin help Disable
  again to post, if wanted.

Summary:
In eg http://mailman.berklix.org/mailman/admin/test/members/list
next to column "mod" there would be a 2nd column eg "self discard".
- "mod" would as before be set by admin to block & store for review.
- "self discard" would discard posts from member, set by member.

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Munich, BSD Linux Unix Systems Engineer
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#stolen_votes  http://berklix.eu/brexit/#eu_passports
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Suggestion: Add a new binary flag: "Discard [or bounce] Sender Posts

[Gretchen R Beck]

Couldn't you just do individuals subscribers  as a spam filter within the 
Privacy options?

Gretchen Beck
Carnegie Mellon

From: Mailman-Users <mailman-users-bounces+cmupythia=cmu@python.org> on 
behalf of Julian H. Stacey <j...@berklix.com>
Sent: Sunday, April 16, 2017 7:27 PM
To: mailman-users@python.org
Cc: Julian H. Stacey
Subject: [Mailman-Users] Suggestion: Add a new binary flag: "Discard [or 
bounce] Sender Posts

Hi mailman-users@python.org
Suggestion: Add a new binary flag: "Discard [or bounce] Posts From Sender
http://berklix.org/~jhs/help/majordomo/#discard_sender

Reason: A mailman list member got his address book harvested by a spammer,
twice spammed a mailman list I run, I removed list member, asked
member to rejoin with an address spammer did not know was subscribed
to list.  Another list member suggested I could instead personaly
moderate all future mail from the spammer harvested address.
http://berklix.org/~jhs/help/majordomo/#harvested

PS (ignore "majordomo" in URLs, I just havent moved text yet.)

PPS Thanks to Mark S & others for replies 22 Mar on "compare lists setup"
still not got back to that - world spins too fast ;-)

Cheers,
Julian
--
Julian Stacey, Computer Consultant, Munich, BSD Linux Unix Systems Engineer
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#stolen_votes  http://berklix.eu/brexit/#eu_passports
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/cmupythia%40cmu.edu
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Suggestion: Add a new binary flag: "Discard [or bounce] Sender Posts

[Mark Sapiro]

On 04/16/2017 04:27 PM, Julian H. Stacey wrote:
> Hi mailman-users@python.org
> Suggestion: Add a new binary flag: "Discard [or bounce] Posts From Sender 


How about setting the user to moderated and setting
member_moderation_action to discard?

If it's just this one (or a few) addresses, that might do what you want.
It wouldn't require moderator action on each post, but it's still an
admin setting, not a user setting. Obviously, if there are other users
who are moderated for other reasons, this won't work, but it woud
address a few of your objections in the "Could List Owners Set Moderated
Bit For Members Who Don't Want To Post ?" section in


-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Suggestion: Add a new binary flag: "Discard [or bounce] Sender Posts

[Julian H. Stacey]

Hi mailman-users@python.org
Suggestion: Add a new binary flag: "Discard [or bounce] Posts From Sender 
http://berklix.org/~jhs/help/majordomo/#discard_sender

Reason: A mailman list member got his address book harvested by a spammer,
twice spammed a mailman list I run, I removed list member, asked
member to rejoin with an address spammer did not know was subscribed
to list.  Another list member suggested I could instead personaly
moderate all future mail from the spammer harvested address.
http://berklix.org/~jhs/help/majordomo/#harvested

PS (ignore "majordomo" in URLs, I just havent moved text yet.)

PPS Thanks to Mark S & others for replies 22 Mar on "compare lists setup"
still not got back to that - world spins too fast ;-)

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Munich, BSD Linux Unix Systems Engineer
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#stolen_votes  http://berklix.eu/brexit/#eu_passports
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] suggestion - wording for one of the admin options

[David]

The following wording is very confusing (especially because of its
similarity to the wording of the next item which has the opposite effect):

Remove message attachments that don't have a matching content type. Leave
 this field blank to skip this filter test.


I would like to propose to the developers the following wording:

Pass message attachments that match a listed content type. Leave this field
 blank to skip this filter test.



And here's a suggestion for the next item too:

Remove message attachments that match a listed filename extension.

http://discuss.fiteyes.com/m/admin/all/?VARHELP=contentfilter/filter_filename_extensions
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] suggestion - wording for one of the admin options

[Mark Sapiro]

David wrote:

The following wording is very confusing (especially because of its
similarity to the wording of the next item which has the opposite effect):

Remove message attachments that don't have a matching content type. Leave
 this field blank to skip this filter test.


I would like to propose to the developers the following wording:

Pass message attachments that match a listed content type. Leave this field
 blank to skip this filter test.



And here's a suggestion for the next item too:

Remove message attachments that match a listed filename extension.


Thanks for your suggestions.

Unfortunately, changes such as these will break the i18n translations
of these messages in all 37 existing translations. I don't think the
need for these changes justifies doing that.

Further, your suggested Pass message attachments that match a listed
content type. Leave this field blank to skip this filter test.
wording seems ambiguous to me as it doesn't say what happens to parts
that don't match. Are they removed unbconditionally or does their
removal depend on other settings? If I were going to make a change, I
think it would need to be more like Pass message attachments that
match a listed content type and remove all others. Leave this field
blank to skip this filter test.

You might consider reporting this against Postorious, the new Mailman 3
web UI under development, at
https://bugs.launchpad.net/postorius/+filebug.

-- 
Mark Sapiro m...@msapiro.netThe highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] suggestion?

[Rick.French]

Good Afternoon

 

Your software was recommended as a solution for my requirements. I am a
Realtor and I would like to be able to send out mass emails to the folks
that have asked to be kept up-to-date. I have tried to send to my list once
but apparently it was viewed as spam and most of the mail came back to me.
Your software was suggested as a package that would assist the handling of
the task. I did download it but it will not work with the windows s/w that I
use as my op system. 

 

Do you have any recommendations that might assist??

 

REALLY appreciate!!

 

Kind Regards

 

Rick French

 

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] suggestion?

[Stephen J. Turnbull]

Rick.French writes:

  Your software was suggested as a package that would assist the
  handling of the task. I did download it but it will not work with
  the windows s/w that I use as my op system.

There are many ISPs/hosting providers that offer Mailman as a service.
There is a good chance that one you already use does provide it, and
if not, competent providers for the level of service you describe are
available at reasonable prices (10s of dollars per month).  However,
make sure the provider actually supports the product; many install a
host management system (cPanel and Plesk are common), and leave the
rest up to you.  This is not a good situation for a business to be in.

Note that Mailman by itself is not a customer relations management
package.  While many people successfully use it for announcements, as
you would like to, it is primarily designed for users to subscribe and
unsubscribe themselves.  While this has its attractions in your use
case, you may also someday want to use the data gathered for other
purposes (eg, figuring what kinds of subscribers actually use your
services; what kinds have the highest satisfaction rate; etc).
Mailman provides no support for that kind of thing.  The data
associated with subscribers is extremely limited: name, email address,
and Mailman-related options (many of which would be irrelevant for an
announce list like yours).  Also, Mailman provides no built-in support
for periodic mailings or forms, nor linkage of mailings to other
databases.

I suggest you do a web search for customer relations management as
well as investigating Mailman providers.

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Suggestion ..

[Khalil Abbas]

hello team..

 

I have a suggestion for you .. it's about importing and exporting the list's 
configuration using the web interface not just shell command using : 
'config_list'.. 

 

this will help those who have mailman with shared hosting plans and have no 
access to server .. not only that, take me for example I have several servers 
with many lists hosted on them.. sometimes I format the servers and create the 
lists using the servers' control panels.. then I have to go to shell to use the 
'config list -i' option ..

 

Thanks ..

 

 
  
_
Windows Live™: Keep your life in sync. Check it out!
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Users] Suggestion ..

[Mark Sapiro]

Khalil Abbas wrote:

I have a suggestion for you .. it's about importing and exporting the list's 
configuration using the web interface not just shell command using : 
'config_list'.. 



This and similar features - e.g. multiple list style templates and
possibly cloning lists will probably be in Mailman 3. See
http://wiki.list.org/x/vgAM.

-- 
Mark Sapiro m...@msapiro.netThe highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Users] Suggestion: do not include List-Id header on subscribe/unsubscribe messages

[Rich Kulawiec]

Reasoning: those messages are not actually mailing list traffic.  Yes,
they're related to the list, and they're about the list, but they're not
being sent through the list per se.

In addition, one of the things that I've noticed is that filtering/filing
based on List-Id (say, a procmail recipe) will filter/file these messages
along with ordinary list traffic.  But I don't think that's desirable
behavior; especially in case of unsubscribe notifications generated on
the server side (say, due to an excess number of undeliverable messages).

Opinions, comments?

---Rsk
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Jon Forrest]

I'm relatively new to Mailman but I've managed
to build it from source and set up a few lists,
with generous help from this list.

While working through issues relating to
creating a standard list configuration, I started
to feel that there was a fundamental flaw in the
way Mailman lists are configured that I couldn't quite put
my finger on. Of course, this could be due me not knowing
or understanding something, and, if so, I'll be happy
to retract what I'm going to say below.

Yesterday, I realized that I had made a mistake in
how I had configured all my lists (I only have about
6 so far, so this is no great tragedy). This was entirely
my fault, and not due to anything amiss in Mailman.
So, using the web interface, I fixed the mistake on
all 6 lists. This wasn't too bad, but it got me to
thinking what I would have had to do if I had 1,000
lists.

All of a sudden the thought hit me that would it
be better if Mailman lists were designed kind of like
classes in an object oriented programming language.
There would be one super list which would be configured
with all the standard values you want every list to have.
Then, there would be lists derived from the super list,
which would only need to be configured to have values
different than the super list. There could even be lists
derived from these lists, and so on down the line.

With this design philosophy it would be very easy to
make changes that effect multiple lists because the
change would only have to be made in one place. I haven't
thought it through but it might even be possible for this
class-like design to include list membership making
it easier to have one list contain other lists as members.

Given that Mailman is written in Python, my naive impression
would be that this should be relatively easy to implement.
(As my old boss Mike Stonebraker used to say, it's just
a simple matter of software).

In reading the Mailman documentation I saw a mention of
an umbrella list, but the only description here says
umbrella lists are depreciated and will be replaced with
a better mechanism for Mailman 3.0. Are umbrella lists
somehow related to what I'm talking about?

Am I completely out to lunch or does this make any sense?

Cordially,



-- 
Jon Forrest
[EMAIL PROTECTED]
Computer Resources Manager
Civil and Environmental Engineering Dept.
305 Davis Hall
Univ. of Calif., Berkeley
Berkeley, CA 94720-1710
510-642-0904
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp

Re: [Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Patrick Bogen]

On 12/6/06, Jon Forrest [EMAIL PROTECTED] wrote:
 I'm relatively new to Mailman but I've managed
 to build it from source and set up a few lists,
 with generous help from this list.

 While working through issues relating to
 creating a standard list configuration, I started
 to feel that there was a fundamental flaw in the
 way Mailman lists are configured that I couldn't quite put
 my finger on. Of course, this could be due me not knowing
 or understanding something, and, if so, I'll be happy
 to retract what I'm going to say below.

 Yesterday, I realized that I had made a mistake in
 how I had configured all my lists (I only have about
 6 so far, so this is no great tragedy). This was entirely
 my fault, and not due to anything amiss in Mailman.
 So, using the web interface, I fixed the mistake on
 all 6 lists. This wasn't too bad, but it got me to
 thinking what I would have had to do if I had 1,000
 lists.
The command-line config_list and/or with_list tools have a slightly
higher up-front cost (in terms of work required), but trivialize the
cost-per-list for config updates, for the purpose of applying a single
value across multiple lists.

 All of a sudden the thought hit me that would it
 be better if Mailman lists were designed kind of like
 classes in an object oriented programming language.
 There would be one super list which would be configured
 with all the standard values you want every list to have.
 Then, there would be lists derived from the super list,
 which would only need to be configured to have values
 different than the super list. There could even be lists
 derived from these lists, and so on down the line.
Someone else can probably give a better analysis, but from my
understanding, something like what you're suggesting would represent a
significant departure from the current Mailman architecture, and this
would constitute a fairly major rewrite.

 With this design philosophy it would be very easy to
 make changes that effect multiple lists because the
 change would only have to be made in one place. I haven't
 thought it through but it might even be possible for this
 class-like design to include list membership making
 it easier to have one list contain other lists as members.

 Given that Mailman is written in Python, my naive impression
 would be that this should be relatively easy to implement.
 (As my old boss Mike Stonebraker used to say, it's just
 a simple matter of software).

 In reading the Mailman documentation I saw a mention of
 an umbrella list, but the only description here says
 umbrella lists are depreciated and will be replaced with
 a better mechanism for Mailman 3.0. Are umbrella lists
 somehow related to what I'm talking about?
Umbrella lists deal with lists that distribute their messages primarly
to other lists, rather than users. So, no, they aren't really related.


-- 
- Patrick Bogen
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp

Re: [Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Dragon]

Patrick Bogen sent the message below at 08:39 12/6/2006:
On 12/6/06, Jon Forrest [EMAIL PROTECTED] wrote:
  I'm relatively new to Mailman but I've managed
  to build it from source and set up a few lists,
  with generous help from this list.
 
  While working through issues relating to
  creating a standard list configuration, I started
  to feel that there was a fundamental flaw in the
  way Mailman lists are configured that I couldn't quite put
  my finger on. Of course, this could be due me not knowing
  or understanding something, and, if so, I'll be happy
  to retract what I'm going to say below.
 
  Yesterday, I realized that I had made a mistake in
  how I had configured all my lists (I only have about
  6 so far, so this is no great tragedy). This was entirely
  my fault, and not due to anything amiss in Mailman.
  So, using the web interface, I fixed the mistake on
  all 6 lists. This wasn't too bad, but it got me to
  thinking what I would have had to do if I had 1,000
  lists.
The command-line config_list and/or with_list tools have a slightly
higher up-front cost (in terms of work required), but trivialize the
cost-per-list for config updates, for the purpose of applying a single
value across multiple lists.

Pretty much true if you understand Python and this tool. It's pretty 
daunting if you do not. It sure would be nice to have some tools that 
don't require knowledge of how Python works to achieve a lot of 
common administrative tasks.

It would also be very nice to have a full templating system to allow 
customizing all web pages and e-mail notifications. (Just one of the 
things I would really like to see, I don't have the Python skills to 
do it myself but I would be willing to help test it...)


  All of a sudden the thought hit me that would it
  be better if Mailman lists were designed kind of like
  classes in an object oriented programming language.
  There would be one super list which would be configured
  with all the standard values you want every list to have.
  Then, there would be lists derived from the super list,
  which would only need to be configured to have values
  different than the super list. There could even be lists
  derived from these lists, and so on down the line.
Someone else can probably give a better analysis, but from my
understanding, something like what you're suggesting would represent a
significant departure from the current Mailman architecture, and this
would constitute a fairly major rewrite.

As far as I can discern from my limited perusing of source code, it 
would be a huge change in architecture. This would probably mean 
throwing out what exists now and restarting from scratch. I believe 
that it has been a stated goal to move list configuration to a real 
database system in future so this may well become a moot point 
if/when that happens.

To be honest this is also probably a better topic of discussion for 
the developers list instead of for this list.


  With this design philosophy it would be very easy to
  make changes that effect multiple lists because the
  change would only have to be made in one place. I haven't
  thought it through but it might even be possible for this
  class-like design to include list membership making
  it easier to have one list contain other lists as members.
 
  Given that Mailman is written in Python, my naive impression
  would be that this should be relatively easy to implement.
  (As my old boss Mike Stonebraker used to say, it's just
  a simple matter of software).

Your old boss obviously has no realistic grasp of the subject.



Dragon

~~~
  Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
~~~

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp

Re: [Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Dec 6, 2006, at 11:59 AM, Dragon wrote:

 As far as I can discern from my limited perusing of source code, it
 would be a huge change in architecture.

This is true.  While a more detailed discussion of this topic belongs  
on the developers list, I will say that my plan is to improve the  
situation in MM2.2 by developing a 'styles' feature.  It won't go as  
far as being object oriented with attribute inheritance, but it will  
allow you to group common attributes in a style, and then apply that  
style either when you create the list or after the fact.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRXb/RnEjvBPtnXfVAQJJRgP9HwRZKMM03JxD09jOqT6VWZWJNzGvP0/9
HeflKT45PejNmRI9r9T3+G8K8fRUn5Ih/byKP7pIRdgSlyKlUs9I9abybdB6KE/4
r89ectug8iYWriZksBf/Gwe9MqzQcMXN6sdJBuJgnlnyKgFjQlxUBl/ccHiAOztD
kFbwZTWVDbc=
=Nkl7
-END PGP SIGNATURE-
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp

Re: [Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Brad Knowles]

At 10:39 AM -0600 12/6/06, Patrick Bogen wrote:

  The command-line config_list and/or with_list tools have a slightly
  higher up-front cost (in terms of work required), but trivialize the
  cost-per-list for config updates, for the purpose of applying a single
  value across multiple lists.

Correct, insofar as it goes.  However, these are command-line tools, 
and one of the things I'd like to see is a move to make it possible 
to do everything that can be done from the web interface, just as 
easily (if not more so) as you can do from the CLI.  But that's a 
very long-term goal.

  Someone else can probably give a better analysis, but from my
  understanding, something like what you're suggesting would represent a
  significant departure from the current Mailman architecture, and this
  would constitute a fairly major rewrite.

Yeah, that would be a huge rewrite.  Now, Mailman3 will be a complete 
rewrite, and this kind of thing would be a perfectly valid subject to 
discuss on that list.  Of course, no one knows when Mailman3 will 
arrive, so again this is a long-term issue.

-- 
Brad Knowles, [EMAIL PROTECTED]

Trend Micro has announced that they will cancel the stop.mail-abuse.org
mail forwarding service as of 15 November 2006.  If you have an old
e-mail account for me at this domain, please make sure you correct that
with the current address.
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp

Re: [Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Brad Knowles]

At 8:26 AM -0800 12/6/06, Jon Forrest wrote:

  Given that Mailman is written in Python, my naive impression
  would be that this should be relatively easy to implement.
  (As my old boss Mike Stonebraker used to say, it's just
  a simple matter of software).

Unfortunately, there are people on this list who won't get that 
reference.  I didn't get it the first few times I heard it.  I had to 
have it explained to me.

For those people, please understand that this is a particularly dry 
form of humor, and the word small is used in more a cosmological 
sense -- as in, anything that exists on this planet is necessarily 
small when compared to the size of the entire Universe.

For more information, see http://catb.org/jargon/html/S/SMOP.html 
and http://en.wikipedia.org/wiki/SMOP.

-- 
Brad Knowles, [EMAIL PROTECTED]

Trend Micro has announced that they will cancel the stop.mail-abuse.org
mail forwarding service as of 15 November 2006.  If you have an old
e-mail account for me at this domain, please make sure you correct that
with the current address.
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp

Re: [Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Brad Knowles]

At 8:59 AM -0800 12/6/06, Dragon wrote:

  Your old boss obviously has no realistic grasp of the subject.

Don't jump to conclusions too quickly.  See my other message first.

-- 
Brad Knowles, [EMAIL PROTECTED]

Trend Micro has announced that they will cancel the stop.mail-abuse.org
mail forwarding service as of 15 November 2006.  If you have an old
e-mail account for me at this domain, please make sure you correct that
with the current address.
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp

[Mailman-Users] [suggestion] non-member thread subscription

[jw schultz]

Let me say that i don't manage or host any lists.  I am,
however, a member of several lists.  As a member of mailing
lists i have a suggestion for a feature that would, i think,
be of benefit to list members an non-members.

As a member of several developer/support lists I often see
postings from people who have a single question.  They don't
wish to subscribe to the list, they just want an answer to
their question or to be able answer questions that list
members may have in response to their suggestion.  My
sending this idea to the mailman list would would qualify.

Their choices are few and problematic.

  o They can subscribe and then cancel the subscription
at a later date -- a hurdle that daunts many and
presents the prospect of inundation.

  o Some poll a list archive -- that causes delays,
heavier load on the archive server and follow-ups
that break threading.

  o Some ask list members to CC them in follow-ups --
sporadic compliance at best resulting in their
address being dropped from the thread and the user
either missing some of the replies or polling the
archives.

All of these choices reduce effective participation and
thereby contribution of those on the perepheri.

I have thought of another possibility.  I call it non-member
thread subscription.  When a posting to a list is made by a
non-member a record associating that non-member's email
address with the thread is created.  When follow-up postings
are made to the thread they also get sent to the thread
subscribers.  This way the non-member could communicate with
the developer community about their single issue in a
fairly transparent manner.

This whole process could be done with a supplementary
program provided it had access to the subscriber list.
This external program would track threads with non-member
posters and forward the follups to them.

As indicated i am not a member of this list.  I put this out
there as a suggestion.  What you do with it is up to you.
In this case i'll not be monitoring the list so if you have
a question you want ME to answer regarding my suggestion you
will have to CC me.

-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt

--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/

This message was sent to: [EMAIL PROTECTED]
Unsubscribe or change your options at
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Suggestion

[J C Lawrence]

On Mon, 1 Apr 2002 07:08:16 -0500 
Ron Kayron Karen Colson Ron wrote:

 I would like to add to the wish list the ability to set (or designate)
 some subscribers for receiving only, withholding from them the ability
 to post to the list.  

This is a current feature of 2.1.

-- 
J C Lawrence
-(*)Satan, oscillate my metallic sonatas. 
[EMAIL PROTECTED]   He lived as a devil, eh?  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.


--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py

[Mailman-Users] Suggestion

[Ron Karen Colson]

I would like to 
add to the wish list the ability to set (or designate) some subscribers for 
receiving only, withholding from them the ability to post to the 
list.
Ron  Karen 
Colson[EMAIL PROTECTED] 

Re: [Mailman-Users] Suggestion

[Jock Coats]

Ron  Karen Colson wrote:

 I would like to add to the wish list the ability to set (or designate) 
 some subscribers for receiving only, withholding from them the ability 
 to post to the list.

 Ron  Karen Colson
 [EMAIL PROTECTED]

  

How big are your lists?  You can do this now in a small way by giving a 
group of addresses the right to post without moderation.  Privacy 
options I think.

-- 


*Jock Coats, JC Solutions  *
*--*
*   M3a Morrell Hall, OXFORD.  OX3 0TU *
* h: +44 1865 485019 f: +44 845 1275714 m: +44 7769 695767 *
*e: [EMAIL PROTECTED]   * 
*w: http://www.jcsolutions.co.uk   *
*--*
*JC Solutions - Constructing Connected Communities *





--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py

[Mailman-Users] Suggestion

[Gary Mills]

I am writing to make a suggestion for your software.  Actually it's not a
suggestion, it's a request.  Would it be possible to have Mailman remove
attachments and strip away all HTML and RTF formatting from messages before
they are posted?

If this feature already exists please tell me how and where to use it.  If
it doesn't exist, please consider making it an option for your users.  The
viruses are running amuck and creating havoc on e-mail lists despite my
repeated cautions to the recipients of my e-mail list.

Thanks,

Gary Mills
Rolla, Missouri


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

R: [Mailman-Users] Suggestion

[Solignani Tiziano]

 I am writing to make a suggestion for your software.  Actually it's not a
 suggestion, it's a request.  Would it be possible to have Mailman remove
 attachments and strip away all HTML and RTF formatting from
 messages before
 they are posted?

That would be wonderful. I see groups at yahoo working this way: every mail
get converted to plain text before being distributed to the subscribers and
every attachment is cut away. Besides security stuff, I cannot stand html
postings... Maybe there is a software which we can use with mailman to do
such a job.

Tiziano


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

[Mailman-Users] Suggestion - cancelable postings

[Nigel Metheringham]

I fairly often get the situation where list postings are sent from the
wrong account (ie not the subscribed account) and so get held for
moderation with a message sent back to the original user.  The user
often fires off another copy (or 2) from the correct email address.

Meanwhile I can get to releasing the moderated postings, so a double
posting hits the list.  In some cases triple postings can happen since I
only skim the message for approrpiateness and do not necessarily see
that there are 2 the same...

One way of helping this situation out, although it then generates a race
condition (between the original poster and the moderator), is that the
notification to the original sender could contain a URL and/or a email
means to allow the original post to be cancelled from the moderation
queue.

Thoughts?

Nigel.
--
[ Nigel Metheringham   [EMAIL PROTECTED] ]
[ Phone: +44 1423 85 Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
[ - Security is not an add-on -- security is a way of life - ]


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Suggestion - cancelable postings

[Barry A. Warsaw]

 NM == Nigel Metheringham [EMAIL PROTECTED] writes:

NM One way of helping this situation out, although it then
NM generates a race condition (between the original poster and
NM the moderator), is that the notification to the original
NM sender could contain a URL and/or a email means to allow the
NM original post to be cancelled from the moderation queue.

Excellent idea.  It should be fairly easy to add with the new MM2.1
confirmation architecture.

The mailback should clearly state the existance of that race
condition.  If the user loses, oh well.

OTOH, if most list moderators are like me, they won't often win that
race. :)

-Barry

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users