Re: mailman keeps holding for non-subscribers

[Eric Wong]

Bob Proulx <address@hidden> wrote:
> Eric Wong wrote:
> > OK, so I'm following half the recommendations
> > 
> > The ones I'm going against are:
> > 
> >     generic_nonmember_action=hold (I want Accept)
> >     default_member_moderation=yes (I want no)
> 
> May I try to convince you otherwise?  Because there are good reasons
> for the recommended settings.

Not unless the maximum delay can be minutes.  In other words,
similar to what greylisting gets without any human interaction.

> > So, should I remove address@hidden from moderators?
> > I still want automated spam filters such as SpamAssassin, though.
> 
> The listhelper anti-spam SpamAssassin et al cancel-bot depends upon
> the hold actions.  If messages do not get held then it has no ability
> to filter spam.  That's fundamental to how it works with Mailman.

That's unfortunate.  I'm not familiar with Mailman, but can't
the MTA feed the message through spam filters before Mailman
ever sees it?

I use mlmmj for legacy mailing list subscribers, that just runs
off cron with no synchronous relationship with the MTA at all.
I have replay script which makes it incrementally read mail from
public-inbox (git).

> > > Additionally any non-spam messages are also approved by the human
> > > team, and their senders either unmoderated or whitelisted.  This
> > > results in the avoidance of spam to the mailing lists while at the
> > > same time avoiding delays in posting as only the initial contact is
> > > held for moderation.  This has been necessary because spammers
> > > routinely subscribe and then post spam.  Therefore we moderate new
> > > addresses as they appear.
> > 
> > I've found automated spam filters good enough on their own and
> > would like to just have those without human moderation.
> 
> My experience is that even with highly tuned automation that it still
> needs continuous training feedback in order to keep accuracy to
> acceptably levels.  Therefore instead of avoiding giving it feedback
> we are giving it continuous feedback.

100% agreed.  I've been using an inotify + Maildir-based
training system since 2008 or so spamc, even pre-public-inbox:

        https://public-inbox.org/dc-dlvr-spam-flow.html

Spam gets trained upon removal from archives.

> Another task of the listhelpers is to periodically review and
> train-on-error the learning engines.  (The learning engines include
> SpamAssassin's Bayes engine and the Bogofilter engine.  But also
> specifically the CRM114 engine which does the best classification for
> us and has been weighted more heavily due to it being most
> successful.)  When we run the queues we are also providing training
> for those engines.  That way as spam is continuously changing in
> character the filters are also continuously being updated.
> 
> However Mailman doesn't have a lot of built in anti-spam ability.  The
> listhelper system is bolted onto the moderation system.  Therefore it
> can only anti-spam the moderated messages.  If the moderation is
> bypassed then so is the anti-spam.  To improve this Mailman itself
> would need to be modified.

I'm not sure Mailman itself needs anti-spam ability.  I'm not
aware of mlmmj having any, either; I'm certainly not using it
if it does.

> > I don't want to have to whitelist anybody, it doesn't scale.
> 
> Perhaps in the large it does not but we are only handling 1500+
> mailing lists and all of the associated subscribers at this time.  I
> don't know how many subscribers in total.  There are 1521 mailing
> lists using listhelper anti-spam right now.  But for small numbers
> such as these it works okay.
> 
> But the real reason is that we are working within the limitations of
> Mailman.  It's the only system Mailman supports.  Therefore it is the
> system we are using.  Improvements would require changes to Mailman.

I've been considering upgrading my (mlmmj|ssoma)-replay script
to support Mailman and maybe other list managers, too; but I
haven't quite had the time and motivation to since I don't use
Mailman.

> > > The resulting process means that as a general statement project
> > > mailing lists need no explicit maintenance.  If you as a project
> > > maintainer and also a maintainer of the mailing list do nothing then
> > > everything happens as needed anyway.  You are however free to be as
> > > involved in the mailing lists as you want.
> > 
> > So if I'm away and unable to administer address@hidden, and
> > generic_nonmember_action is "Hold"; does the "human team" at GNU
> > will eventually accept postings in my absence?
> 
> Yes.  Eventually usually means a few hours.

<snip> yikes, that seems like a lot of human labor :<

> > > > The list in question is address@hidden
> > > 
> > > I don't recall any interaction with that mailing list.  It doesn't
> > > ring a bell with me.
> > > 
> > > > I don't want to force users to subscribe to the mailing list to
> > > > post(*).
> > > 
> > > Agreed.  How is that statement related to generic_nonmember_action set
> > > to Hold?  Seems unrelated.
> > 
> > I mean that I don't want any artificial delays in handling new,
> > unsubscribed users (in case the admins are away or unavailable).
> > I'd rather let an occasional spam through.
> 
> It is your mailing list and this is up to you.  But people tend to be
> very intolerant of spam on mailing lists.

It depends on the quantity, I suppose.  vger.kernel.org lets a
few through and nobody seems to mind.  (I'm just a subscriber
on vger, not an admin)

> For example if people receive their mail at Gmail or Yahoo or
> wherever, and then spam to the mailing list is received at their
> mailbox, and they push the Spam button, this teaches Google and Yahoo
> and so forth that lists.gnu.org is a source of spam and may create
> problems for normal mailing list delivery.  This has been more of a
> problem with Yahoo than most other places.  Some spam is of course
> inevitable but we try to keep it to a minimum.  If it becomes a
> problem then if not us volunteers then FSF admin will need to become
> involved.  Getting blacklisted due to spam is a pain to deal with.

Yes, that is a problem.  It's part of the reason public-inbox is
slowly moving mailing lists into a "pull" subscriber model over
NNTP/Atom/HTML (and maybe even POP3).

> The only thing we really must insist upon is to discard spam and not
> reject spam.  Most spam uses forged from addresses.  Therefore
> rejecting spam ala Mailman Reject usually sends a rejection message to
> an innocent 3rd party who then gets "backscatter" spam.  They validly
> report lists.gnu.org as a spam source in that case and it gets us in
> trouble with the DNSBLs.  Therefore please do not Reject random spam
> messages.

Right.  One of my concerns with increased reliance on whitelisting
is that spammers will start using whitelisted addresses themselves.
SPF might discourage that, though.

Fwiw, vger.kernel.org just drops HTML, which seems to cut a lot
of spam, too.  They also do greylisting from what I can discern.

> It is okay however to send a Reject to a human who would benefit from
> the message.  I usually include a note with the rejection as to why.
> There are a number of reasons.  Such as sending administrivia to the
> mailing list members.  Or trying to subscribe to a private closed
> list.  Or whatever.  A Reject for specific explicit reasons is okay.
> Just not to the incoming spam generally.  Use judgement and Do The
> Right Thing.

Backscatter is a pain, yes.  For the MTA feeding public-inboxes
I run: it rejects HTML and tells users to resend as plain text,
but only if it passes other anti-spam checks, so there's not much
backscatter from spam.

> > > > In my case, it was myself since I've been changing email
> > > > addresses because of the uncertainty around being able to afford
> > > > .org down the line.
> > > 
> > > I will guess that you changed your email address, your first message
> > > sent to the mailing list was therefore new and never before seen, it
> > > was held for moderation.  Is that the issue here?
> > 
> > Maybe.  I had the same issue on Feb 3, 2020 and pushed my
> > message through.  I refused to whitelist myself out of
> > principle.
> 
> I keep thinking I will jump in and start hacking on Mailman.  But life
> and time is what keeps everything from happening all at once.  Until
> then I am much more pragmatic and work with the tools that are
> provided to me to work with.  However having said that I created the
> entire bolted-on listhelper anti-spam because I hated being a user of
> the mailing lists with all of the spam that was on the lists before
> and was not happy with the tools provided.  But at the time I had no
> way to modify Mailman.  And I am not a python person, the source
> language for Mailman, so that was an activation energy situation for
> me to hack on Mailman.  So I did something else.

Understood :>  Python didn't fit my Perl-infected brain, either,
and the 2-to-3 mess put me off of learning it.