Mailman Auto-unsubscribes Bad Addresses?

Bug #266316 reported by Bascherz
2
Affects Status Importance Assigned to Milestone
GNU Mailman
Invalid
Medium
Unassigned

Bug Description

I haven't seen any settings for this, and I can only
describe it based on the information that I have. But
today I received bounce notices identically
timestamped for three separate email addresses in the
same domain. The notices all indicated the addresses
had been unsubscribed from a specific Mailman list. I
don't know what initiated the action, and these same
addresses are still subscribed to other, less-
frequently used lists.

I sent emails directly to the three addresses to
notify them of the issue, and I got back a response
from their email server as follows (actual email
addresses omitted or replaced for privacy reasons):

- - - - - - - - - - - - - - - -
Return-Path: <>
X-Envelope-To: <my_email_address>
X-Spam-Status: No, hits=2.4 required=5.0
 tests=AWL: -0.181,HTML_30_40:
0.879,HTML_MESSAGE: 0.001,
 MIME_HTML_MOSTLY: 1.54,VIRUS_WARNING268B: 0.2
X-Spam-Level: **
Return-Path: <>
Delivered-To: <my_email_address>
Received: (qmail 29847 invoked by uid 399); 23 Feb
2006 17:21:13 -0000
X-Virus-Scan: Scanned by clamdmail 0.15 (no viruses);
  Thu, 23 Feb 2006 11:21:13 -0600
Received: from unknown (HELO eastrmmtao06.cox.net)
(68.230.240.33)
  by mail.opentransfer.com with SMTP; 23 Feb 2006
17:21:13 -0000
To: <my_email_address>
From: Mail Administrator <email address hidden>
Reply-To: <email address hidden>
Subject: Mail System Error - Returned Mail
Date: Thu, 23 Feb 2006 12:21:06 -0500
Message-ID: <omitted>
MIME-Version: 1.0
Content-Type: multipart/report;
  report-type=delivery-status;

 Boundary="===========================_ _=
9638061(9108)1140715266"

--===========================_ _= 9638061(9108)
1140715266
Content-Type: text/plain

 This Message was undeliverable due to the following
reason:

 Each of the following recipients was rejected by a
remote mail server. The reasons given by the server
are included to help you determine why each recipient
was rejected.

    Recipient: <email address hidden>
    Reason: #5.1.1 bad address <email address hidden>

    Recipient: <email address hidden>
    Reason: #5.1.1 bad address <email address hidden>

    Recipient: <email address hidden>
    Reason: #5.1.1 bad address <email address hidden>
- - - - - - - - - - - - - - - -

So, all three addresses are bad. Does Mailman
automatically unsubscribe addresses if it can't
deliver to them? Or, is there a way to spoof it to
get it to delete addresses? Is it possible the email
server (erols.com in this case) can determine that
there are messages being sent from a Mailman email
list and send unsubscribe requests to the Mailman
server to make them stop?

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

Revision history for this message
Bascherz (bascherz) wrote :

I failed to mention that the webhosting company has
Mailman v2.1.6 installed.

Revision history for this message
Mark Sapiro (msapiro) wrote :

I am closing this because mailman is doing what it should.
The users were unsubscribed by bounce processing. The
settings for this are list by list on the Bounce processing
page of the admin web interface.

Mailman registers the bounce notices that it receives in
response to post deliveries and handles them according to
bounce settings. The remote server has no direct involvement
with the unsubscribe. It just returns a notice to mailman
just like the notice returned to you when you mailed these
addresses directly. The process is described on the Bounce
processing page.

And yes, bounce notifications can be spoofed, but with
normal default settings, the spoofer would have to send 5
spoofed notices on different days, and then the member would
have list delivery disabled and be sent a warning, and be
sent two more warnings at one week intervals before being
unsubscribed. Also, you can select the option to notify the
list owner when the subscription is disabled, so
unsubscribing a user by spoofing bounces is not likely to be
successful if the user actually has any interest in the list.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.