Posters set to Mod, incorrectly Rejected should be Held

Bug #266322 reported by Ws28
2
Affects Status Importance Assigned to Milestone
GNU Mailman
New
Medium
Unassigned

Bug Description

Mailman 2.1.6(slightly hacked)
SunOS xxx 5.8
Sendmail

I've setup a group nis_mailman_test.

1- Privacy options/Sender filters/Action to take when a
moderated member posts to the list is set to Hold.

2- <same>/By default, should new list member postings
be moderated is set to No

3- I've added my members via a script that calls
add_members with the options "-w n -a n".

4- So after adding the members, all members can post.

5- Change this by going into Membership
Management/Additional Member tasks/Set everyones
moderation... set to On.

> To review, before step 5, the mod column for all
members "mod" was unchecked. (At that point anyone
could post without admin/moderator assistance.) After
step 5 the mod column for all members is checked.

6- Checking the Privacy options/Sender filters/Action
to take when a moderated member posts to the list we
find that it is set to Hold

7- Also checking I thought there was a "should I tell
the user that their email is being held?" and if I
remember correctly this is set to Yes.

> so at this point if a member sends a post they SHOULD
get an email saying "I've held your email until the
moderator approves it".

> unfortunately at this point the member gets an email
stating: "The e-mail account does not exist at the
organization this message was sent to. Check the
e-mail address, or contact the recipient directly to
find out the correct address."

ok so lets try something different

1- delete all users
2- change the Membership Management/Additional Member
tasks/Set everyones moderation from No to On
3- Add all of the users
4- attempt a post from a user
> this produces the correct behavior, an email is sent
to the member stating "hey Im holding this until
approved" AND the moderator gets an email "do you want
to approve this".

So the bug is that changing the users moderation flag
from off to on is NOT the same as subscribing a user
with the "Action to take when a moderated member posts
to the list" set on.

Bill
bsaunder2002 somwhereat <what a cowboy yells, when he
sees a pretty cowgirl(unless it's like Brokeback
mountain but you get the gist)>.com
read that spammers!

[http://sourceforge.net/tracker/index.php?func=detail&aid=1446859&group_id=103&atid=100103]

Revision history for this message
Mark Sapiro (msapiro) wrote :

<quote>
> unfortunately at this point the member gets an email
stating: "The e-mail account does not exist at the
organization this message was sent to. Check the
e-mail address, or contact the recipient directly to
find out the correct address."
</quote>

This doesn't come from Mailman. It comes from the MTA.
Unless the MTA is actually checking list membership before
accepting posts, the poster sent the post to the wrong address.

<quote>
1- delete all users
2- change the Membership Management/Additional Member
tasks/Set everyones moderation from No to On
</quote>

Which does absolutely nothing at this point besause there
are no members to set to 'moderated'.

<quote>
3- Add all of the users
4- attempt a post from a user
> this produces the correct behavior, an email is sent
to the member stating "hey Im holding this until
approved" AND the moderator gets an email "do you want
to approve this".
</quote>

And how did steps 1 - 4 produce a moderated member?

<quote>
So the bug is that changing the users moderation flag
from off to on is NOT the same as subscribing a user
with the "Action to take when a moderated member posts
to the list" set on.
</quote>

I don't see how the above statement follows from your tests,
notwithstanding the fact that it is an apples/oranges type
of statement. I.e., the moderation flag and the action are
not an either/or situation. They are two independent
settings that work in concert.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.