[Mailman-Developers] [ mailman-Bugs-550462 ] New feature: Automoderate microsoft user
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 29 Apr 2002 18:53:53 -0700
Bugs item #550462, was opened at 2002-04-29 21:53
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=100103&aid=550462&group_id=103
Category: (un)subscribing
Group: 2.1 beta
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Whitis (whitis)
Assigned to: Nobody/Anonymous (nobody)
Summary: New feature: Automoderate microsoft user
Initial Comment:
I am not using mailman at the moment but I was looking at its feature list and planned upgrades and found this missing. And it could be added
in a very general form that could support
many other uses.
Reason for suggesting: everytime I post a message
on a Linux list, I get a bunch of virus messages
from bozos who have subscribed to those lists
from a windows box. And I am certainly not
alone in that respect. Usually these messages
do not arrive via the list but are sent to anyone
who posts to the list (often by lurkers). Users of
real operating systems who subscribe to lists related to those should not be inconvinienced
by those who use microsoft products, there of
all places.
I would like to suggest that future versions of
Mailman include a feature (selected by the moderator)
which automatically takes certain actions based
on the subscibers email client. This feature
could be activated based on the message headers
in the replies to subscription confirmation messages.
Actions could include:
- Placing the user in moderated status
(prevents sending virus to the list
directly but doesn't prevent the virus
from getting addresses from the user).
- Cancelling the subscription
- Sending a warning message to the user
- Requiring the user to send a control message
agreeing that their virus software will
be kept up to date.
- hide or mung all email addresses in copies
of messages delivered to this user so
email worms/viruses cannot harvest them.
The email client status could be updated when the user sends a new control message.
Optionally, it could also detect microsoft platforms via the browser ID when people sign on via the web site.
Detection could be controlled by a configuration file listing with four fields: action, mail/web, field,
and regex:
ACCEPT MAIL X-Mailer .*Microsoft Sucks.*
REJECT MAIL X-Mailer .*Microsoft Outlook.*
REJECT MAIL X-Mimeole .*Microsoft Exchange.*
REJECT WEB Browser-ID .*Internet Explorer.*
(note: this would be triggered by opera
in identify as Internet Explorer mode, but
the user can switch to identify as opera).
REJECT WEB Browser-ID .*Windows 95.*
REJECT WEB Browser-ID .*Windows 98.*
REJECT WEB Browser-ID .*Windows NT.*
REJECT WEB Browser-ID .*Windows ME.*
REJECT WEB Browser-ID .*Windows 2000.*
REJECT WEB Browser-ID .*Win16.*
REJECT WEB Browser-ID .*Win32.*
REJECT WEB Browser-ID .*MSIE.*
If you place someone on moderated status based on their mail client or web browser, the reason
for moderation should be noted so that they can
be automatically un-moderated (if otherwise consistent with policy) when they use a real computer to access the list.
This feature could also be used to protect some
protection against other problems, as well. Spam,
REJECT MAIL From .*hotmail.com.*
REJECT MAIL Subject: .*casino.*
REJECT ATTACH Content-Type: application/octet-stream
REJECT ATTACH Content-Type: audio/x-wav
REJECT ATTACH Content-Type: audio/x-midi
REJECT BODY "insurance"
MODERATE-MSG BODY "profaneword"
The config file could be XMLized:
<filter action="reject" source="mail" header="X-Mailer" contents=".*microsoft.*" />
Possible Extensions:
action: make "actions" instead and allow a comma
separated list (or even nested XML action tags)
moderate-msg
moderate-user
unmoderate-user
strip-attachments
strip-attachment
bounce-message
append-boilerplate
source: comma separated list
WEB_POST, WEB_CONTROL, MAIL_POST, MAIL_CONTROL, POST_BODY, POST_ATTACHMENT_HDR,
POST_ATTACHMENT_BODY.
blacklist: added field.
.rss.mail-abuse.org
.dul-mail-abuse.org
Note that for the Dial Up list, this should
only be applied to the first Received line
added by the mail server itself.
user-status: the users existing status
(normal, moderated, moderated-newbie,
moderated-badsoftware, trusted,
moderator, list_owner, etc.)
could be considered in applying filters.
XML structure could be much more complicated, as
well.
<filter userclass="..." source="...">
<pattern>
</pattern>
<pattern>
<exception>
<pattern>
</pattern>
</exception>
</pattern>
<blacklist>
</blacklist>
</filter>
One could also allow a user so detected to subscribe only after they had pledged to
keep their virus checker up to date by sending
a special control message or visiting a special
web page.
This could also be used to filter certain types
of spam that have consistent patterns. I have
seen the same websites repeately spammed to the
same list (until I blew those websites away) from
different aliases.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=100103&aid=550462&group_id=103