Re: mailman keeps holding for non-subscribers
Bob Proulx wrote: > Eric Wong wrote: > > Bob Proulx 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. > > The initial contact delay is the hill being defended? On a mailing > list that may have many interactions over time. You and I might be > discussing some topic. Say the topic of mailing list operations. :-) > We may send many messages back and forth on the mailing list. This > might go on for years and years over many topics. Each of those > happen fast and efficiently. And it is not the continuing problem of > spam to the mailing list that is a problem. 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 and far-off Date: headers being flagged as spam by subscribers' MTAs is another. The main factor of all the admins being potentially unavailable for long periods of time (or permanently) is a worry of mine. 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. > 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. > 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. > > > > So, should I remove listhel...@gnu.org 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? > > It's interesting that you mention that. Because for years and years > the frontend anti-spam was poor. Very poor. And this is not a > reflection upon the current FSF staff who have inherited the present > situation. But that is the traditional situation. For a very long > time the frontend anti-spam has been very poor. And therefore we have > been implementing the anti-spam portion mostly in the Mailman > interface where it is possible for volunteers to interact with the > system. > > There has been discussion of how to improve the frontend anti-spam. > At this time the systems are getting OS upgrades. Those are dearly > needed. And obviously a first step in the improvement of the system. > And there have been discussion about what needs to be done to improve > the frontend anti-spam. This is starting to happen. But is still > going to take a while from now to be improved. As with many things > life and time is what keeps everything from happening all at once. understood. > > > 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). > > If we are going to start listing out mailing list management software > But Mailman is an official GNU Project. There is a benefit to "eating > your own dogfood" as the saying goes. That and due to other reasons > the lists.gnu.org machine is likely to continue to run GNU Mailman > instead of other mailing list manager programs for a while to come. Fwiw, I'm not advocating mlmmj, either; but more wondering if Mailman and mlmmj are similar enough that it's easy to make the
Re: mailman keeps holding for non-subscribers
Eric Wong wrote: > Bob Proulx 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. The initial contact delay is the hill being defended? On a mailing list that may have many interactions over time. You and I might be discussing some topic. Say the topic of mailing list operations. :-) We may send many messages back and forth on the mailing list. This might go on for years and years over many topics. Each of those happen fast and efficiently. And it is not the continuing problem of spam to the mailing list that is a problem. That spam is okay. But it is the very first initial contact email message delay that is the showstopper? It's beyond the pale? 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? 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. > > > So, should I remove listhel...@gnu.org 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? It's interesting that you mention that. Because for years and years the frontend anti-spam was poor. Very poor. And this is not a reflection upon the current FSF staff who have inherited the present situation. But that is the traditional situation. For a very long time the frontend anti-spam has been very poor. And therefore we have been implementing the anti-spam portion mostly in the Mailman interface where it is possible for volunteers to interact with the system. There has been discussion of how to improve the frontend anti-spam. At this time the systems are getting OS upgrades. Those are dearly needed. And obviously a first step in the improvement of the system. And there have been discussion about what needs to be done to improve the frontend anti-spam. This is starting to happen. But is still going to take a while from now to be improved. As with many things life and time is what keeps everything from happening all at once. However given the flow of mail and spam there needs to be a way to train the learning engines. As we just mentioned in the previous emails in our thread. Right now Mailman provides a reasonably convenient hook location to provide that training. One that is not as easy to do without the mailing list manager. Improving the feedback location in the flow of email is something to look at doing. But there is a lot of associated work that needs to happen first before working on that aspect of the problem. > 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). If we are going to start listing out mailing list management software that is better than Mailman then we had better get comfortable. It's a long list! I am not a fan of Mailman. Mailman presents a pretty low threshold. I would start with Smartlist which is very capable and scales well. Also I have long been a fan of the way ezmlm works, if only it didn't require qmail. And at one time I would have said that Enemies of Carlotta had interesting features for a mailing list. For that matter I actually like the venerable old Majordomo. One of the very active mailing lists I interact with still to this day uses Majordomo for it! But Mailman is an official GNU Project. There is a benefit to "eating your own dogfood" as the saying goes. That and due to other reasons the lists.gnu.org machine is likely to continue to run GNU Mailman instead of other mailing list manager programs for a while to come. > 100% agreed. I've been using an
