[Mailman-Users] rejecting spam disables local subscribers on remotelists

[Mark Sapiro]

James Ralston wrote:

>We recently implemented a policy such that any incoming message that
>scores higher than 10 with SpamAssassin is rejected at our MX servers
>with:
>
>    550 5.7.0 message not delivered due to suspect content


A SpamAssassin score of 10 is pretty liberal. I suspect your users are
getting copious spam from their list subscriptions with scores in the
< 3 to 9.9 range :-)


>We've discovered that this policy has interaction problems with
>recipients at our site who are subscribed to external mailing lists.
>Here's what happens:
>
>    1.  Someone at our site is subscribed to a random Mailman mailing
>        list on the Internet.
>
>    2.  The owners of the mailing list have made little to no attempt
>        to filter spam.  As a result, the mailing list passes on spam
>        to subscribers at our site.
>
>    3.  We detect the spam that Mailman attempts to relay to our
>        subscribers and reject it per above.
>
>    4.  Mailman, upon receiving the bounces, assumes that the messages
>        bounced because the recipient addresses are no longer valid,
>        and disables and/or removes them.
>
>    5.  Our users, upon being given the brush-off by Mailman at the
>        remote site, blame us.


Yes, I see the problem.


>The fundamental problem is that the owners of the mailing list, by not
>taking steps to protect their list from spam, are essentially
>operating an opt-in spam amplification and relaying system.  But given
>that we have no control over how these individuals [mis]manage their
>mailing lists, we are pondering how to best address this issue on our
>end.


And I wonder how the users separate the wheat from the chaff on these
lists and why they want to subscribe to them in the first place, but I
digress ...


>I just looked at Mailman/Bouncers/DSN.py, to see if Mailman was
>looking at the Status field of the message/delivery-status part, but
>alas, Mailman only pays attention to the Action field.  Therefore, no
>matter what we return as the DSN code, Mailman will assume that any
>permanent failure occurred because the recipient address was invalid.


Well, really just undeliverable. That's why bounce processing is
tunable to require bounces on n separate days with no m-day
bounce-free periods in between and to disable delivery and send a
number of warning messages at intervals before actually removing the
user.

But you're right, we could be more discerning about specific status,
but even if we change this, by the time these offending sites install
the upgrade, you will have solved the problem some other way anyway.


>One possibility would be to not reject incoming messages if they
>appear to be from Mailman.  (We use David Skoll's excellent MIMEDefang
>package, so we easily have this capability.)  But spammers are a
>devious and clever lot; I have no doubts that they'd quickly realize
>that they could bypass our spam blocking simply by adding a few
>Mailman headers to their messages.


You are possibly correct here, but I doubt that spammers would spend
the effort just for CMU (where the recipient base is possibly
sophisticated enough that their response rate is at the 'too low to
bother if there's any cost involved' level anyway).


>Another possibility would be to allow our recipients to opt out of the
>spam rejecting.  But this is a last-ditch option.


Actually, as a user, this would be the option I'd prefer, but I'm
probably not a typical user.


>Have others encountered this situation?  If so, how did you deal with
>it?


I don't recall seeing this on the list before, but I hope others will
jump in with ideas.

-- 
Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan