From andreas at eversberg.eu Sat Jan 4 15:19:34 2014 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 04 Jan 2014 16:19:34 +0100 Subject: Multislot allocation failures and defects In-Reply-To: <20131226100313.GA19501@xiaoyu.lan> References: <20131226100313.GA19501@xiaoyu.lan> Message-ID: <52C82686.9090705@eversberg.eu> Holger Hans Peter Freyther wrote: > * select_first_ts (it exists after the refactoring). It initializes > i and compares it but it will never increment it. This means that > the code can look at PDCHs _outside_ of the tx_range. > > * first_common_ts handling. When assigning the DL tbf we pick a > first_common_ts but when the actual UL assignment happens there > might not be a free USF on the Uplink and at that point the phone > might not listen on the TS we think. > > * Sum for Rx+Tx is not used. I see that in update_rx_win_max you > modify the window to make some room. > > * select_ul_slots. "i" is not incremented in all cases which could > potentially lead to using slots outside of the tx_range. For the > MS Type == 1 handling you could introduce a different variable that > counts how many slots were used? > dear holger, i added serveral fixes that showed up with your test code. i have pushed them to the jolly/allocation-fixes branch. in also includes a fix for the missing incrementation of 'i' in select_first_ts() and select_ul_slots(). the Sum variable is not used, because the algorithm assigns only one uplink time slot. the supports RX slots plus 1 TX slot never exceeds the Sum. i have no fix for the USF problem. if the first_common_ts on concurrent TBFs is different, we should reject the TBF by sending a Packet Access Reject, but this message is also not implemented. regards, andreas From holger at freyther.de Sat Jan 11 19:22:05 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 11 Jan 2014 20:22:05 +0100 Subject: Coverity issues in gsm_rlcmac.cpp In-Reply-To: References: <20131111192408.GD30839@xiaoyu.lan> <20131225143504.GA18757@xiaoyu.lan> Message-ID: <20140111192205.GA1853@xiaoyu.lan> On Mon, Dec 30, 2013 at 02:47:53PM +0400, Ivan Kluchnikov wrote: > Hi Holger, > > I merged my patch to the master branch. > Please, check it. Daniel has merged this to sysmocom/master and jenkins points out that the result of RLCMactest changed. Could you please look at the result and check if that is correct or wrong? diff --git a/tests/rlcmac/RLCMACTest.ok b/tests/rlcmac/RLCMACTest.ok index 99117ff..22744ed 100644 --- a/tests/rlcmac/RLCMACTest.ok +++ b/tests/rlcmac/RLCMACTest.ok @@ -53,6 +53,6 @@ vector1 = 4016713dc09427ca2ae57ef90906aafc001f80222b +++++++++Finish DECODE++++++++++ =========Start ENCODE============= +++++++++Finish ENCODE+++++++++++ -vector1 = 4016713dc09427ca2ae57ef90906aafc001f80222b -vector2 = 4016713dc09427ca2ae57ef90906aafc001f80222b -vector1 == vector2 : TRUE +vector1 = 4016713dc09427d001da10906aafc001f80222b +vector2 = 4016713dc0942691001da10906aafc0b2b2b2b2b +vector1 == vector2 : FALSE From laforge at gnumonks.org Sun Jan 12 18:53:26 2014 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 12 Jan 2014 19:53:26 +0100 Subject: [RFC] [ADMIN] Making lists subscriber-only? Message-ID: <20140112185326.GU23594@nataraja> Dear all, so far the osmocom.org mailing lists have always been in a 'non-members are manually moderated' mode. This has created a lot of work for manual list moderation, where a lot of the messages caught are simply spam, and only the occasional valid message is being received. I'd like to thank the list moderators for taking care of this. However, in more recent discussions, we were considering to move the lists to a completely closed mode, i.e. postings would automatically be rejected from non-members. The automatic response would contain a description of how to subscribe in 'nomail' mode, i.e. to subscribe in a way to be able to post to the list, while still not receiving any incoming traffic. The latter should be fine for occasional posters who don't want the bulk e-mail that goes with a full/regular subscription. Please provide feedback in case you disagree with that change. Unless there is major opposition, we will likely transition to the 'closed' mode within one month. Thanks, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From kaber at trash.net Sun Jan 12 19:38:55 2014 From: kaber at trash.net (Patrick McHardy) Date: Sun, 12 Jan 2014 19:38:55 +0000 Subject: [RFC] [ADMIN] Making lists subscriber-only? In-Reply-To: <20140112185326.GU23594@nataraja> References: <20140112185326.GU23594@nataraja> Message-ID: <20140112193855.GB13545@macbook.localnet> On Sun, Jan 12, 2014 at 07:53:26PM +0100, Harald Welte wrote: > Dear all, > > so far the osmocom.org mailing lists have always been in a 'non-members > are manually moderated' mode. This has created a lot of work for manual > list moderation, where a lot of the messages caught are simply spam, and > only the occasional valid message is being received. > > I'd like to thank the list moderators for taking care of this. > > However, in more recent discussions, we were considering to move the > lists to a completely closed mode, i.e. postings would automatically be > rejected from non-members. > > The automatic response would contain a description of how to subscribe > in 'nomail' mode, i.e. to subscribe in a way to be able to post to the > list, while still not receiving any incoming traffic. The latter should > be fine for occasional posters who don't want the bulk e-mail that goes > with a full/regular subscription. > > Please provide feedback in case you disagree with that change. Unless > there is major opposition, we will likely transition to the 'closed' > mode within one month. For the dect list I'm all in favour of this. There's very low traffic and almost only spam. Cheers, Patrick From nikos.balkanas at eyeonix.com Mon Jan 13 10:12:01 2014 From: nikos.balkanas at eyeonix.com (Nikos Balkanas) Date: Mon, 13 Jan 2014 12:12:01 +0200 Subject: [RFC] [ADMIN] Making lists subscriber-only? In-Reply-To: <20140112185326.GU23594@nataraja> References: <20140112185326.GU23594@nataraja> Message-ID: I, for one, agree totally. Not that i have received *any* spam from this list, but your proposal makes sense. Not that would stop spam, though, they do fake addresses sometimes :-( But because that's how all of the lists, that I know of, work. PS You didn't specify for "personal" feedback, so I am replying to the lists, many of whom I am not a member. Hope it is not considered spam ;-) BR, Nikos On Sun, Jan 12, 2014 at 8:53 PM, Harald Welte wrote: > Dear all, > > so far the osmocom.org mailing lists have always been in a 'non-members > are manually moderated' mode. This has created a lot of work for manual > list moderation, where a lot of the messages caught are simply spam, and > only the occasional valid message is being received. > > I'd like to thank the list moderators for taking care of this. > > However, in more recent discussions, we were considering to move the > lists to a completely closed mode, i.e. postings would automatically be > rejected from non-members. > > The automatic response would contain a description of how to subscribe > in 'nomail' mode, i.e. to subscribe in a way to be able to post to the > list, while still not receiving any incoming traffic. The latter should > be fine for occasional posters who don't want the bulk e-mail that goes > with a full/regular subscription. > > Please provide feedback in case you disagree with that change. Unless > there is major opposition, we will likely transition to the 'closed' > mode within one month. > > Thanks, > Harald > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwillmann at sysmocom.de Wed Jan 15 09:05:26 2014 From: dwillmann at sysmocom.de (Daniel Willmann) Date: Wed, 15 Jan 2014 10:05:26 +0100 Subject: [PATCH 1/1] Set csnStream direction *after* csnStreamInit Message-ID: <6f0796a33adf989db18ba6aae5cb64806049c435.1389776658.git.daniel@totalueberwachung.de> Fixes a bug introduced in commit 402cdc. That commit sets direction to zero so setting it to 1 should be done after the call to csnStreamInit(). This issue was discovered by the rlcmac test. --- src/csn1.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/csn1.cpp b/src/csn1.cpp index 7f64823..258f7c9 100644 --- a/src/csn1.cpp +++ b/src/csn1.cpp @@ -544,11 +544,11 @@ csnStreamDecoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector, unsig guint8 length = bitvec_read_field(vector, readIndex, length_len); LOGPC(DCSN1, LOGL_NOTICE, "%s length = %d | ", pDescr->sz , (int)length); - arT.direction = 1; bit_offset += length_len; remaining_bits_len -= length_len; csnStreamInit(&arT, bit_offset, length); + arT.direction = 1; Status = serialize(&arT, vector, readIndex, pvDATA(data, pDescr->offset)); if (Status >= 0) -- 1.8.4.2 From dwillmann at sysmocom.de Wed Jan 15 09:20:56 2014 From: dwillmann at sysmocom.de (Daniel Willmann) Date: Wed, 15 Jan 2014 10:20:56 +0100 Subject: Coverity issues in gsm_rlcmac.cpp In-Reply-To: <20140111192205.GA1853@xiaoyu.lan> References: <20131111192408.GD30839@xiaoyu.lan> <20131225143504.GA18757@xiaoyu.lan> <20140111192205.GA1853@xiaoyu.lan> Message-ID: <20140115092056.GI23205@adrastea.totalueberwachung.de> Hi, On Sat, 2014-01-11 at 20:22, Holger Hans Peter Freyther wrote: > On Mon, Dec 30, 2013 at 02:47:53PM +0400, Ivan Kluchnikov wrote: > > Hi Holger, > > > > I merged my patch to the master branch. > > Please, check it. > > Daniel has merged this to sysmocom/master and jenkins points out > that the result of RLCMactest changed. Could you please look at > the result and check if that is correct or wrong? we just found the issue. In one instance the direction was set before csnStreamInit which of course doesn't work anymore. See my patch in a different mail. I already pushed it to sysmocom/master and master as it fixes the test failure. Regards, Daniel -- - Daniel Willmann http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From hfreyther at sysmocom.de Wed Jan 15 09:59:35 2014 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Wed, 15 Jan 2014 10:59:35 +0100 Subject: Multislot allocation failures and defects In-Reply-To: <52C82686.9090705@eversberg.eu> References: <20131226100313.GA19501@xiaoyu.lan> <52C82686.9090705@eversberg.eu> Message-ID: <20140115095935.GP26608@xiaoyu.lan> On Sat, Jan 04, 2014 at 04:19:34PM +0100, Andreas Eversberg wrote: > dear holger, dear andreas, > > i added serveral fixes that showed up with your test code. i have pushed > them to the jolly/allocation-fixes branch. in also includes a fix for > the missing incrementation of 'i' in select_first_ts() and > select_ul_slots(). I merged your changes and the crazy test that tested all combinations started to work so I went ahead an merged your change. What Daniel (and the jenkins) noticed is that I didn't update the test result. I asked him to update the test result but he pointed out that there appears to be a genuine regression: @@ -409,7 +409,6 @@ PDCH[5] is first common for DL PDCH[5] is used for UL PDCH[6] is used for UL -PDCH[7] is used for UL PDCH[5] is control_ts for UL PDCH[5] is first common for UL PDCH[5] is used for DL @@ -420,7 +419,6 @@ Testing jolly example PDCH[1] is used for UL PDCH[2] is used for UL -PDCH[3] is used for UL PDCH[1] is control_ts for UL PDCH[1] is first common for UL PDCH[1] is used for DL so it appears that the multislot algorithm started to not assign/use the last timeslot. Could you please have a look at that? > i have no fix for the USF problem. if the first_common_ts on concurrent > TBFs is different, we should reject the TBF by sending a Packet Access > Reject, but this message is also not implemented. I will add a todo to the code. -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From andreas at eversberg.eu Wed Jan 15 12:58:27 2014 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 15 Jan 2014 13:58:27 +0100 Subject: Multislot allocation failures and defects In-Reply-To: <20140115095935.GP26608@xiaoyu.lan> References: <20131226100313.GA19501@xiaoyu.lan> <52C82686.9090705@eversberg.eu> <20140115095935.GP26608@xiaoyu.lan> Message-ID: <52D685F3.10109@eversberg.eu> Holger Hans Peter Freyther wrote: hi holger, thanx for merging the patches. > @@ -409,7 +409,6 @@ > PDCH[5] is first common for DL > PDCH[5] is used for UL > PDCH[6] is used for UL > -PDCH[7] is used for UL > PDCH[5] is control_ts for UL > PDCH[5] is first common for UL > PDCH[5] is used for DL > @@ -420,7 +419,6 @@ > Testing jolly example > PDCH[1] is used for UL > PDCH[2] is used for UL > -PDCH[3] is used for UL > PDCH[1] is control_ts for UL > PDCH[1] is first common for UL > PDCH[1] is used for DL > > so it appears that the multislot algorithm started to not assign/use > the last timeslot. Could you please have a look at that? > If you look at patch "alloc_algorithm_b: Increment 'i', so allocated TS will not exceed tx_range", i added the missing "i++" in for-loops. inside one loop there is an incrementation (already), which needs to be removed: - if (++i == ms_max_txslots) { + if (i+1 == ms_max_txslots) { I compared the output of the AllocTest with the expected output. Now they match. regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-alloc_algorithm_b-Remove-obsolete-i-incrementation-f.patch URL: From jolly at eversberg.eu Wed Jan 15 12:53:43 2014 From: jolly at eversberg.eu (Andreas Eversberg) Date: Wed, 15 Jan 2014 13:53:43 +0100 Subject: [PATCH] alloc_algorithm_b: Remove obsolete 'i' incrementation from for-loop Message-ID: --- src/gprs_rlcmac_ts_alloc.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gprs_rlcmac_ts_alloc.cpp b/src/gprs_rlcmac_ts_alloc.cpp index 58dd2e9..366732c 100644 --- a/src/gprs_rlcmac_ts_alloc.cpp +++ b/src/gprs_rlcmac_ts_alloc.cpp @@ -459,7 +459,7 @@ inc_window: "1 slot assigned\n"); break; } - if (++i == ms_max_txslots) { + if (i+1 == ms_max_txslots) { LOGP(DRLCMAC, LOGL_DEBUG, "- Done, because " "slots / window reached maximum " "allowed Tx size\n"); -- 1.8.1.5 --------------010607040705070003040009-- From Ivan.Kluchnikov at fairwaves.ru Wed Jan 15 13:44:21 2014 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Wed, 15 Jan 2014 17:44:21 +0400 Subject: Coverity issues in gsm_rlcmac.cpp In-Reply-To: <20140115092056.GI23205@adrastea.totalueberwachung.de> References: <20131111192408.GD30839@xiaoyu.lan> <20131225143504.GA18757@xiaoyu.lan> <20140111192205.GA1853@xiaoyu.lan> <20140115092056.GI23205@adrastea.totalueberwachung.de> Message-ID: Good catch, Daniel, Thank you for fixing this bug! 2014/1/15 Daniel Willmann : > Hi, > > On Sat, 2014-01-11 at 20:22, Holger Hans Peter Freyther wrote: >> On Mon, Dec 30, 2013 at 02:47:53PM +0400, Ivan Kluchnikov wrote: >> > Hi Holger, >> > >> > I merged my patch to the master branch. >> > Please, check it. >> >> Daniel has merged this to sysmocom/master and jenkins points out >> that the result of RLCMactest changed. Could you please look at >> the result and check if that is correct or wrong? > > we just found the issue. In one instance the direction was set before > csnStreamInit which of course doesn't work anymore. See my patch in a > different mail. I already pushed it to sysmocom/master and master as it > fixes the test failure. > > > Regards, > Daniel > > -- > - Daniel Willmann http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Schivelbeiner Str. 5 > * 10439 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte -- Regards, Ivan Kluchnikov. http://fairwaves.ru From hfreyther at sysmocom.de Wed Jan 15 16:35:10 2014 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Wed, 15 Jan 2014 17:35:10 +0100 Subject: Multislot allocation failures and defects In-Reply-To: <52D685F3.10109@eversberg.eu> References: <20131226100313.GA19501@xiaoyu.lan> <52C82686.9090705@eversberg.eu> <20140115095935.GP26608@xiaoyu.lan> <52D685F3.10109@eversberg.eu> Message-ID: <20140115163510.GD18114@xiaoyu.lan> On Wed, Jan 15, 2014 at 01:58:27PM +0100, Andreas Eversberg wrote: > I compared the output of the AllocTest with the expected output. Now they match. applied. osmo-pcu is back to green/blue on the CI. -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From hfreyther at sysmocom.de Wed Jan 15 16:38:45 2014 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Wed, 15 Jan 2014 17:38:45 +0100 Subject: [PATCH 1/1] Set csnStream direction *after* csnStreamInit In-Reply-To: <6f0796a33adf989db18ba6aae5cb64806049c435.1389776658.git.daniel@totalueberwachung.de> References: <6f0796a33adf989db18ba6aae5cb64806049c435.1389776658.git.daniel@totalueberwachung.de> Message-ID: <20140115163845.GF18114@xiaoyu.lan> On Wed, Jan 15, 2014 at 10:05:26AM +0100, Daniel Willmann wrote: Hi Ivan, > Fixes a bug introduced in commit 402cdc. That commit sets direction to > zero so setting it to 1 should be done after the call to > csnStreamInit(). FYI there was a communication issue between Daniel and me. I had asked him to push the patch to "*master". So this fix is already in your master. holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From Ivan.Kluchnikov at fairwaves.ru Thu Jan 16 06:14:56 2014 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Thu, 16 Jan 2014 10:14:56 +0400 Subject: [PATCH 1/1] Set csnStream direction *after* csnStreamInit In-Reply-To: <20140115163845.GF18114@xiaoyu.lan> References: <6f0796a33adf989db18ba6aae5cb64806049c435.1389776658.git.daniel@totalueberwachung.de> <20140115163845.GF18114@xiaoyu.lan> Message-ID: Hi Holger, ok, I understood. 2014/1/15 Holger Hans Peter Freyther : > On Wed, Jan 15, 2014 at 10:05:26AM +0100, Daniel Willmann wrote: > > Hi Ivan, > > >> Fixes a bug introduced in commit 402cdc. That commit sets direction to >> zero so setting it to 1 should be done after the call to >> csnStreamInit(). > > > FYI there was a communication issue between Daniel and me. I had asked > him to push the patch to "*master". So this fix is already in your master. > > > holger > > -- > - Holger Freyther http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Schivelbeiner Str. 5 > * 10439 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru From hfreyther at sysmocom.de Thu Jan 16 09:05:04 2014 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Thu, 16 Jan 2014 10:05:04 +0100 Subject: State of sysmocom/master and upcoming work Message-ID: <20140116090504.GK18114@xiaoyu.lan> Hi, Daniel and me spent another day in the sysmocom office to go through the PCU code. We finished clean-ups, made some simple manual tests and looked at the traces. We will work on the following items during the next weeks: * For DL handling and multi-slot allocation more than one slot will only be allocated _after_ the TBF is re-used. E.g. for a simple download this might mean a single slot is used for the entire download. Daniel made a prototype to send a packet downlink assignment directly _after_ the assignment through the CCCH has completed. We manage to run into a use after free in the TBF code but will work on it. The issue is that the start of a TBF will take a bit longer. We might want to add some heuristic to decide when or when not to do it. * Re-sending and window stalls. When the entire window has been sent once, resending will start but when the ACK/NACK is arrived the resending will conntinue. As it is more likely that frames have arrived we should stop the resending and increase the window. This will increase the throughput. cheers holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From edoardo.rispoli at gmail.com Mon Jan 13 22:46:47 2014 From: edoardo.rispoli at gmail.com (Edoardo Rispoli) Date: Mon, 13 Jan 2014 23:46:47 +0100 Subject: [RFC] [ADMIN] Making lists subscriber-only? In-Reply-To: <20140112185326.GU23594@nataraja> References: <20140112185326.GU23594@nataraja> Message-ID: ok for the closed mode ! 73 IW3BTI 2014/1/12 Harald Welte > Dear all, > > so far the osmocom.org mailing lists have always been in a 'non-members > are manually moderated' mode. This has created a lot of work for manual > list moderation, where a lot of the messages caught are simply spam, and > only the occasional valid message is being received. > > I'd like to thank the list moderators for taking care of this. > > However, in more recent discussions, we were considering to move the > lists to a completely closed mode, i.e. postings would automatically be > rejected from non-members. > > The automatic response would contain a description of how to subscribe > in 'nomail' mode, i.e. to subscribe in a way to be able to post to the > list, while still not receiving any incoming traffic. The latter should > be fine for occasional posters who don't want the bulk e-mail that goes > with a full/regular subscription. > > Please provide feedback in case you disagree with that change. Unless > there is major opposition, we will likely transition to the 'closed' > mode within one month. > > Thanks, > Harald > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevie.glass at gmail.com Tue Jan 14 08:21:06 2014 From: stevie.glass at gmail.com (Steve Glass) Date: Tue, 14 Jan 2014 18:21:06 +1000 Subject: [RFC] [ADMIN] Making lists subscriber-only? In-Reply-To: <20140112185326.GU23594@nataraja> References: <20140112185326.GU23594@nataraja> Message-ID: <52D4F372.8010403@gmail.com> Hi Closed lists will just be more efficient. If the bounce message is clear then most genuine contributors will get that and respond appropriately. I've only dealt with one real, actual problem as a moderator and it was purely accidental that the offender wasn't a subscriber and I was able to catch it. We should expect some spammers to join but even this hurdle will eliminate the majority and we can boot any subscribed spammers quite quickly. ATB Stevie From e_tews at seceng.informatik.tu-darmstadt.de Wed Jan 15 08:28:34 2014 From: e_tews at seceng.informatik.tu-darmstadt.de (Erik Tews) Date: Wed, 15 Jan 2014 09:28:34 +0100 Subject: [RFC] [ADMIN] Making lists subscriber-only? In-Reply-To: <20140112185326.GU23594@nataraja> References: <20140112185326.GU23594@nataraja> Message-ID: <1389774514.6112.2.camel@lima> Am Sonntag, den 12.01.2014, 19:53 +0100 schrieb Harald Welte: > Dear all, > > so far the osmocom.org mailing lists have always been in a 'non-members > are manually moderated' mode. This has created a lot of work for manual > list moderation, where a lot of the messages caught are simply spam, and > only the occasional valid message is being received. > > I'd like to thank the list moderators for taking care of this. > > However, in more recent discussions, we were considering to move the > lists to a completely closed mode, i.e. postings would automatically be > rejected from non-members. > > The automatic response would contain a description of how to subscribe > in 'nomail' mode, i.e. to subscribe in a way to be able to post to the > list, while still not receiving any incoming traffic. The latter should > be fine for occasional posters who don't want the bulk e-mail that goes > with a full/regular subscription. > > Please provide feedback in case you disagree with that change. Unless > there is major opposition, we will likely transition to the 'closed' > mode within one month. Hi The only disadvantage I can see is, that you cannot simply CC the list, when you get a question to your personal address, that might be interesting for the list. Your mail will still get through, but the next reply will not make it to the list. But that is quiet acceptable, compared to a lot of spam being send to such lists. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: