[
https://issues.apache.org/jira/browse/WHIMSY-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736014#comment-16736014
]
Sebb commented on WHIMSY-233:
-----------------------------
Ezmlm notes
==========
mail mod requests are stored under list/mod/pending
After processing, the original file is deleted, and an empty file created under
list/mod/rejected or list/mod/accepted
The same file name is used, and this can be derived from the mod request (it is
the timestamp), so a regular listing of the file names would allow Whimsy to
keep track of which requests were still pending
AFAICT there are no such files used for subscription requests.
The accept email address contains an encoding of the subscriber and the mailing
list.
[I suspect that is why there is no way to reject a sub request - ezmlm has no
record]
The email address also contains a timestamp; I think ezmlm won't accept ones
that are more than 10 days old.
> New workbench to support mail moderation
> ----------------------------------------
>
> Key: WHIMSY-233
> URL: https://issues.apache.org/jira/browse/WHIMSY-233
> Project: Whimsy
> Issue Type: New Feature
> Reporter: Sebb
> Priority: Major
>
> Mail moderation sends the same email to each of the moderators, so they all
> have to scan all the mails. It would be a lot more efficient if each mail
> could be dealt with once.
> The suggestion is to implement this in Whimsy.
> The code could be derived from the Secretary workbench.
> This issue is to keep track of requirements etc.
> Functionality needs to include:
> - store mails for posts, subscriptions and reponses
> - show only unprocessed mails (and dynamically update the list)
> - Flag a mail as accepted (and/or allowed)
> - Reject a mail with a suitable message (templates would be useful here)
> - Flag a mail as spam (don't reject)
> - Accept a subscription request (check that the email address is in LDAP so
> can validate it)
> - authorise the moderator so they only process mails for lists they are
> allowed to see.
> Optionally:
> - detect mails that look like spam, e.g. they are very similar to ones
> already flagged
> - detect when requests no longer exist on the mail server. e.g. they were
> processed elsewhere, or expired
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
