Some may be interested to know how GroupServer processes posts. Below are the
fourteen checks that GroupServer carries out when a post comes in. I have
broken it into two sections: checks on the user, checks on the message.
Checks on the user are made in the context of group. They ensure that the user
has all the rights required to post. Eventually, Alice and I will split these
seven checks off into a class that can be called by the Web interface and the
email message processing interface. Then we will need to create a notification
for each check!
Posting pember: Check to see if the user a posting member of the
group. Only posting members can post to a group.
Verified address: As of this morning, GroupServer checks to ensure
that the address, from which the post has been sent, is verified.
Posting limits: Limit the number of posts that a user can make in a
given period, unless the user is a special user who the normal
rules do not apply.
Blocked: Check to see if the user is banned from posting. (There is
no UI for this, but the check remains in the code.)
Required properties: Block the user from posting if the user does
not have the required properties filled. This needs to be
expanded to required site-properties, as well as group properties.
Moderated: Process a post differently if the user is moderated. This
is not really a posting check, as the user can post. However, I
include it here, as it is very closely-related to the posting
checks.
Unclosed: Only allowing posting post to groups that have not been
closed (which is different to an Open group).
Message checks are made to each message. Most of these are security measures,
and do not require notifications.
Correct IP: We only process messages from mail transfer agents that
we know and trust. This is to prevent hacking.
X-Mailer loop: Do not process a message if we have already seen it.
Tight loop: Do not process a message if we have just seen it.
Already added: Do not post a message if it has already been added
to the group.
Empty return path: Only process messages that have a return path set.
Command: Always process commands
Spam: An internal check against manually-set "bad" words. (I kid
you not, you can prevent people saying ".*water.*" in the Canterbury
Issues Forum!) A notification should go out if we get a "bad"
word.
I am currently working on rewriting the code that determines if a person can
post to a group or not, and it turns out that my estimates of how many checks
are required were a little shy of the mark: there are eight checks, excluding
moderation, not six. The current list is as follows.
1. The first check is to see if the group restricts who can post. Support
groups, for example, allow anyone to post.
2. If there are restrictions, check if the user is a member of the system. This
requires people who post using the Web interface to log in first.
3. Check if the user is a member of the group.
4. Check if the user has valid email addresses (we do not want people without
verified email addresses to post).
5. Check if the user is a posting member. Not all members of a group can post:
announcement groups often restrict who can post.
6. Check if the posting limits been hit. This restricts "me too" posts
clogging up the system. Participation coaches and (in the new code)
administrators are not subject to this restriction.
7. Check if the user been specifically blocked from posting. There is no user
interface for this, as moderation takes care of most of the use case for
this feature.
8. Check if all the required user-properties for the site and the group have
been set. The required properties for a site are set at a global level,
while individual groups can require particular user-properties to be set.
I have finished the conversion and testing of the new Can the User Post code,
which I have been working on. I have come across some rather interesting
properties of GroupServer mailing lists that I had not seen before.
One is the ability to block messages from a particular email address.
Currently, if this happens, the message is dropped, without any notification.
Should I change it so that any post from the *user* that has that email address
is blocked? This way the user would be prevented from posting via the Web, or
we could also send the user a notification by email. Bonus question: should we
still block these messages from unclosed groups?
On Thu, 2008-07-24 at 17:15 +1200, Michael JasonSmith wrote:
> I have finished the conversion and testing of the new Can the User Post
> code, which I have been working on. I have come across some rather
> interesting properties of GroupServer mailing lists that I had not
> seen before.
>
> One is the ability to block messages from a particular email address.
> Currently, if this happens, the message is dropped, without any
> notification. Should I change it so that any post from the *user* that
> has that email address is blocked? This way the user would be
> prevented from posting via the Web, or we could also send the user a
> notification by email. Bonus question: should we still block these
> messages from unclosed groups?
Quite possibly it should be any post from a user who has that email
address is blocked. e-democracy use this feature to prevent users who
have been abusive from posting. It should definitely block these
messages from 'unclosed/open' groups too. (in that case the email
address check would still be very important).
Thanks for the advice, Richard. I will keep it in mind as I think about
where the different methods should go ☺
