[Mailman-Developers] [ mailman-Bugs-550462 ] New feature: Automoderate microsoft user

noreply@sourceforge.net noreply@sourceforge.net
Tue, 13 Aug 2002 04:37:56 -0700

Bugs item #550462, was opened at 2002-04-30 03:53
You can respond by visiting: 

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)









    source: comma separated list



     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,

           moderated-badsoftware, trusted,   

           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

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.


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: