New feature: Automoderate microsoft user

[Whitis-users]

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.

[http://sourceforge.net/tracker/index.php?func=detail&aid=550462&group_id=103&atid=350103]

[Cfaerber-users (cfaerber-users)]

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).

[Barry Warsaw (barry)]

This seems like an awful lot of complexity for something
that probably won't work anyway. I'm moving this to the
feature request tracker, but rejecting it because it's not
something I'm interesting in working on. If you are though,
feel free to generate a patch for Mailman 2.1 and upload it
to the patch manager. No guarantees it will go in, but at
least that way, others can look at and comment on the approach.

[Jean.c.h (slug71)]

Marked this bug as 'Invalid' due to its age and nothing further has been added in a long time. New versions have been released since as well as some underlying stuff in the OS platform itself.

If this bug still affects then please change status back to 'Confirmed'.