Re: mailman keeps holding for non-subscribers

[Bob Proulx]

Eric Wong wrote:
> Bob Proulx wrote:
> > That spam is okay.  But it is the very first initial contact email
> > message delay that is the showstopper?  It's beyond the pale?
> 
> The delay is one of the factors

I think we will simply have to agree to disagree.  However to be clear
the configuration of your mailing list is up to you.

> and far-off Date: headers being flagged as spam by subscribers' MTAs
> is another.

This is the first I have heard of any problem of messages so far
delayed that anti-spam filters flag them due to the delay.

Has this actually happened with any of the GNU mailing lists?  Or is
that a problem that is being remembered from other mailing lists?

If it is a problem with the GNU mailing lists then please do make
reports of any such problems.

> The main factor of all the admins being potentially unavailable
> for long periods of time (or permanently) is a worry of mine.

That is why teams are good.  That way it is more than just one
person.  And if someone does get abducted by aliens then another in
the team can make noise that more help is needed to replace them.

> Maybe the admin team here is big enough here for that not to be
> a big problem.  I've definitely participated in some groups
> where admins disappeared for days or even weeks while mail piled
> up.

We all get behind at times...

> > How about SMTP time greylisting?  I would gather from this discussion
> > so far that SMTP greylisting, which is exactly the same and creates a
> > delay upon the initial contact, would also be a showstopper too then?
> > Greylisting at SMTP time would also be beyond the pale?
> 
> Fwiw, I see greylisting as a "less bad" option because messages
> still eventually go through when no admins are available.  I
> prefer not to have greylisting at all, but it's better than
> needing humans to be constantly in the loop.
...
> So with that, I really don't think involving human labor at
> initial contact (and potential for human error) is good at all.

I'll just say that I disagree but thank you for making your position
clear.  The things are you worried about happening are not a problem
with the GNU mailing lists as we have them set up now.  I understand
that you disagree.

> > I am sorry but IMNHO it is the daily day to day operations that are
> > much more important to optimize and make efficient.  Because those are
> > things that happen repeatedly, day after day.  One time startup costs
> > should not be too onerous, but may have some cost in order to have
> > benefit.  Like greylisting.  But it is the repeated operations that I
> > think should be targeted for optimization.  And that is the normal day
> > to day use of the mailing lists without having them filled with spam.
> 
> Interesting that you say that, especially when you rightly
> admit humans also make mistakes in letting spam through, below.

I don't see any conflict in the information I wrote.

> Fwiw, I'm not advocating mlmmj, either; but more wondering if
> Mailman and mlmmj are similar enough that it's easy to make the
> existing replay script work with Mailman, as well.

I did not see a script called "replay" listed in the diagram at the
URL you posted.  The name hints at an action that is not clear to me
how it applies to a mailing list.  Therefore I have no opinion about
it since I have no idea what it does.

Bob