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