Re: mailman keeps holding for non-subscribers
I ran out of popcorn >:-( On Wed, 15 Apr 2020 09:04:01 + Eric Wong wrote: > Bob Proulx wrote: > > I think we will simply have to agree to disagree. However to be > > clear the configuration of your mailing list is up to you. > > That's fine :> I wish your (hopefully big) team the best. > > > 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. > > Oops, `ssoma-replay'. I think it was named `mlmmj-replay' at > some point... But it relies on ssoma, which only worked on v1 > inboxes(*). I'll probably rewrite *-replay it to use NNTP one > day, so the server(s) running the outgoing mail delivery won't > even need to keep a message on the SMTP server. But here it > is in its current state: > > https://public-inbox.org/public-inbox.git/tree/scripts/ssoma-replay > > (*) https://public-inbox.org/public-inbox-v1-format.html > > And the flow diagram can get really complex, because anybody > can replay any inbox to anybody else...
Re: mailman keeps holding for non-subscribers
Bob Proulx wrote: > I think we will simply have to agree to disagree. However to be clear > the configuration of your mailing list is up to you. That's fine :> I wish your (hopefully big) team the best. > 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. Oops, `ssoma-replay'. I think it was named `mlmmj-replay' at some point... But it relies on ssoma, which only worked on v1 inboxes(*). I'll probably rewrite *-replay it to use NNTP one day, so the server(s) running the outgoing mail delivery won't even need to keep a message on the SMTP server. But here it is in its current state: https://public-inbox.org/public-inbox.git/tree/scripts/ssoma-replay (*) https://public-inbox.org/public-inbox-v1-format.html And the flow diagram can get really complex, because anybody can replay any inbox to anybody else...
Re: mailman keeps holding for non-subscribers
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
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 existi
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 inot
Re: mailman keeps holding for non-subscribers
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. > > 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? 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 dtas-...@nongnu.org, 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. yikes, that seems like a lot of human labor :< > > > > The list in question is dtas-...@nongnu.org > > > > > > 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?
Re: mailman keeps holding for non-subscribers
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. > 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. > > 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. 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 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. > > 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 dtas-...@nongnu.org, 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. If you had done nothing you would have experienced what any other poster to the mailing lists would experience. There would have been a short delay until a moderator from the listhelper team saw the message and approved it, whitelisted or unmoderated your address, and then subsequent messages would have been passed through by Mailman without delay. Sometimes there are longer or shorter delays for someone to see a message. Personally my own schedule allows me to look at the message queues several times a day on most days. But sometimes I am busy away from the keyboard for a day. However I am but one of the team and there are several of us who look at the queues and it is the overlapping schedules of everyone that fills in time periods. It's not organized and a bit of chaos and randomness but a new address rarely sits in the hold queue for more than half a day. And worst case one of us would get to the queues at least once a day at the worst. But most days it would be a few hours. I really should do some statistical work to plot the delay times out. It's on my list for one of these days to do. And that moderation hold is only for the initial contact. Subsequent messages are passed through without delay. Therefore the usual posters to a mailing list will see no delays. They will converse all as normal. Plus there is no need to be subscribed to post a message. There may be mechanical delays due to all of the normal reasons of email however but that is outside of the anti-spam processes. > > > The list in question is dtas-...@nongnu.org > > > > I don't
Re: mailman keeps holding for non-subscribers
Bob Proulx wrote: > Eric Wong wrote: > > Hello Savannah admins, > > Mailing lists have little to do with Savannah. I have CC'd the > mail...@gnu.org list with this response. That's the place to talk > about all things related to Mailman and the GNU mailing lists. > Savannah is all about the software source forge. OK. I think I only put the project on Savannah because it was the only service which offered mailing lists without JavaScript or CAPTCHAs at the time. > > It seems every few months I need to login to the Mailman admin > > interface and change the `generic_nonmember_action' option to > > "Accept" postings for non-subscribers. > > > > Is there some cronjob or upgrade which keeps flipping that > > option to "Hold"? > > I am not aware of any automated process which does that. However that > is the standard configuration for new mailing lists. It's a good > configuration. It is the recommended configuration. But if you > change it as far as I know nothing will fight you over it. > > This is described in some detail here. > > https://savannah.gnu.org/maintenance/ListHelperAntiSpam/ 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) So, should I remove listhel...@gnu.org from moderators? I still want automated spam filters such as SpamAssassin, though. > The normal thing is that the listhelper cancel-bot will receive the > moderation notices, deduce messages that are spam, automatically > discard those spam messages from the hold queue. The anti-spam is > conservative as a false positive is worse than a false negative. > Remaining spam is discarded by the listhelper team. We roll up all of > the 1500+ lists as a collection. Agreed that false positives are worse than false negative. > 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. I don't want to have to whitelist anybody, it doesn't scale. > 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 dtas-...@nongnu.org, and generic_nonmember_action is "Hold"; does the "human team" at GNU will eventually accept postings in my absence? > > The list in question is dtas-...@nongnu.org > > 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. > We never want to require people to subscribe to post bug reports or > other messages. The GNU mailing lists are open mailing lists. Can > you imagine requiring someone to subscribe in order to post a bug > report? That would be inconvenient enough to drive most bug reporters > away. > > Although some maintainers have made subscription a requirement for > their project mailing lists. It goes against our recommendation and > guidelines. I strongly recommend against it. OK, I'm glad we agree there :> > > 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. Thanks.
Re: mailman keeps holding for non-subscribers
Eric Wong wrote: > Hello Savannah admins, Mailing lists have little to do with Savannah. I have CC'd the mail...@gnu.org list with this response. That's the place to talk about all things related to Mailman and the GNU mailing lists. Savannah is all about the software source forge. > It seems every few months I need to login to the Mailman admin > interface and change the `generic_nonmember_action' option to > "Accept" postings for non-subscribers. > > Is there some cronjob or upgrade which keeps flipping that > option to "Hold"? I am not aware of any automated process which does that. However that is the standard configuration for new mailing lists. It's a good configuration. It is the recommended configuration. But if you change it as far as I know nothing will fight you over it. This is described in some detail here. https://savannah.gnu.org/maintenance/ListHelperAntiSpam/ The normal thing is that the listhelper cancel-bot will receive the moderation notices, deduce messages that are spam, automatically discard those spam messages from the hold queue. The anti-spam is conservative as a false positive is worse than a false negative. Remaining spam is discarded by the listhelper team. We roll up all of the 1500+ lists as a collection. 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. 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. > The list in question is dtas-...@nongnu.org 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. We never want to require people to subscribe to post bug reports or other messages. The GNU mailing lists are open mailing lists. Can you imagine requiring someone to subscribe in order to post a bug report? That would be inconvenient enough to drive most bug reporters away. Although some maintainers have made subscription a requirement for their project mailing lists. It goes against our recommendation and guidelines. I strongly recommend against it. > 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? Bob
mailman keeps holding for non-subscribers
Hello Savannah admins, It seems every few months I need to login to the Mailman admin interface and change the `generic_nonmember_action' option to "Accept" postings for non-subscribers. Is there some cronjob or upgrade which keeps flipping that option to "Hold"? The list in question is dtas-...@nongnu.org I don't want to force users to subscribe to the mailing list to post(*). 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. Thank you. (*) In fact, I hate subscriptions so much I started a project years ago to prioritize archives over subscriptions :> https://public-inbox.org/README
