[ mailman-Bugs-550462 ] New feature: Automoderate microsoft user
Tue, 13 Aug 2002 04:37:56 -0700
Bugs item #550462, was opened at 2002-04-30 03:53
You can respond by visiting:
Group: 2.1 beta
Submitted By: Mark Whitis (whitis)
Assigned to: Nobody/Anonymous (nobody)
Summary: New feature: Automoderate microsoft user
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
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,
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.*" />
action: make "actions" instead and allow a comma
separated list (or even nested XML action tags)
source: comma separated list
WEB_POST, WEB_CONTROL, MAIL_POST, MAIL_CONTROL, POST_BODY, POST_ATTACHMENT_HDR,
blacklist: added field.
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,
moderator, list_owner, etc.)
could be considered in applying filters.
XML structure could be much more complicated, as
<filter userclass="..." source="...">
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
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
Comment By: Claus Färber (cfaerber)
Date: 2002-08-13 13:37
Logged In: YES
The problem with misdirected bounce messages, etc. is not caused by
the the operating system or the user agent. It is caused by virus
scanners, vacation programmes, and even some broken MTAs that
send messages back to addresses in the header and not to the return
path (envelope from).
Mailman could try to trigger that bug by
sending a message -- for example, the monthly reminder -- with the correct
return path but with a different from address. If some software then
causes a bounce to be sent to the wrong address, Mailman could act
accordingly (e.g. unsubscribe the user, or activate a broken-mailer flag).
You can respond by visiting: