Hello, I need to know why the options i have uncommented in the rc.custom file don't seem to be working. I am running version 3.15, I need to restrict access to employees only. I have an accept list, i have uncommented foreign_submit = yes , and still see outside e-mail to the list. Jerry Sloan Network Services Administrator fP Technologies, Inc jerry@fptech.net
On Wed, Dec 27, 2000 at 04:38:12PM -0500, Jerry Sloan wrote:
I need to know why the options i have uncommented in the rc.custom file don't seem to be working. I am running version 3.15, I need to restrict access to employees only. I have an accept list, i have uncommented foreign_submit = yes , and still see outside e-mail to the list.
That's because "foreign_submit = yes" means "allow foreign submission". Try "foreign_submit = no". And don't worry - many people find the syntax unclear. What's commented out is in fact the default state, provided for your reference - if you want something other than the default, you have to put it in yourself. Roger
Well i had an idea that yes meant yes..but when i changed to no I could still send e-mail to my list with my personal provider, and it get posted... -----Original Message----- From: smartlist-admin@lists.RWTH-Aachen.DE [mailto:smartlist-admin@lists.RWTH-Aachen.DE]On Behalf Of Roger Burton West Sent: Wednesday, December 27, 2000 4:46 PM To: SmartList-list Subject: Re: need help On Wed, Dec 27, 2000 at 04:38:12PM -0500, Jerry Sloan wrote:
I need to know why the options i have uncommented in the rc.custom file don't seem to be working. I am running version 3.15, I need to restrict access to employees only. I have an accept list, i have uncommented foreign_submit = yes , and still see outside e-mail to the list.
That's because "foreign_submit = yes" means "allow foreign submission". Try "foreign_submit = no". And don't worry - many people find the syntax unclear. What's commented out is in fact the default state, provided for your reference - if you want something other than the default, you have to put it in yourself. Roger _______________________________________________ Smartlist mailing list Smartlist@lists.RWTH-Aachen.DE http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
Well i had an idea that yes meant yes..but when i changed to no I could still send e-mail to my list with my personal provider, and it get posted...
Are you certain that you are not subscribed from your provider address..... This can happen if you have uncommented the part in rc.custom that controls automatic subscription of any adddress that sends to the list. -------------------------------------------------------------------------- #force_subscribe force_subscribe= yes # uncomment to cause people to # be autosubscribed upon first # submission to the list --------------------------------------------------------------------------- To check for your address at your personal provider look in the 'dist' and 'accept' file in the list directory for a match to your personal address. --Joyce
At 4:46 PM -0500 12/27/00, Roger Burton West is rumored to have typed:
That's because "foreign_submit = yes" means "allow foreign submission". Try "foreign_submit = no".
It'll work (if I remember, the code looks for "y" in the variable), but it makes a lot more sense to unset the variable as instructed in your default rc.custom.
And don't worry - many people find the syntax unclear.
Er...they do? If foreign_submit=yes, submissions from foreign addresses (those not subscribed) are accepted...foreign submissions...foreign_submit, get it? Seems pretty darned clear to me, anyway...especially if you actually read the comments listed in the rc.custom file.
What's commented out is in fact the default state, provided for your reference - if you want something other than the default, you have to put it in yourself.
Actually, that's not correct at all, since _both_ states are clearly in the rc.custom file. The default rc.custom file will have _two_ examples for most flags (yes/no settings), with different comment structures for the lines, as in (using the foreign_submit as an example): #foreign_submit = yes ##foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list Note that the first one has a single hash mark (#) denoting the comment, and the second line has a double hash mark. This means simply (and throughout the rc.custom file) that the one with the single hash mark is the pre-set default (set this way in rc.init), and the one with the double hash mark will _change_ the default setting to the opposite setting if uncommented. The rc.custom file is terribly consistant in this regard...read through it carefully and you'll see what I mean. Also, in this case, note that the default file contains _specific_ instructions on how to set this flag properly...it doesn't say uncomment the line above, but "this line" to restrict submissions. "This line," the one with the double hash marks, clearly unsets the variable (making it dissapear from the environment as if it never existed), and doesn't set it to "no" or "uh-huh" or any other value. (It doesn't even set it to a null value...it makes it dissapear in a flash of smoke.) Although I'd agree that some of the more esoteric settings in rc.custom might be a little confusing, this one is in my humble opinion TERRIBLY straight-forward, excellently notated, and should only cause confusion for those people who decide not to read the comments clearly typed out therein. It _does_ occasionally cause confusion, but I think Philip would be hard-pressed to make it any clearer. Charlie
Thanks Charlie, point noted..I most likely didn't read far enough or the right doc -----Original Message----- From: smartlist-admin@lists.RWTH-Aachen.DE [mailto:smartlist-admin@lists.RWTH-Aachen.DE]On Behalf Of Charlie Summers Sent: Wednesday, December 27, 2000 6:08 PM To: Roger Burton West; SmartList-list Subject: Re: need help At 4:46 PM -0500 12/27/00, Roger Burton West is rumored to have typed:
That's because "foreign_submit = yes" means "allow foreign submission". Try "foreign_submit = no".
It'll work (if I remember, the code looks for "y" in the variable), but it makes a lot more sense to unset the variable as instructed in your default rc.custom.
And don't worry - many people find the syntax unclear.
Er...they do? If foreign_submit=yes, submissions from foreign addresses (those not subscribed) are accepted...foreign submissions...foreign_submit, get it? Seems pretty darned clear to me, anyway...especially if you actually read the comments listed in the rc.custom file.
What's commented out is in fact the default state, provided for your reference - if you want something other than the default, you have to put it in yourself.
Actually, that's not correct at all, since _both_ states are clearly in the rc.custom file. The default rc.custom file will have _two_ examples for most flags (yes/no settings), with different comment structures for the lines, as in (using the foreign_submit as an example): #foreign_submit = yes ##foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list Note that the first one has a single hash mark (#) denoting the comment, and the second line has a double hash mark. This means simply (and throughout the rc.custom file) that the one with the single hash mark is the pre-set default (set this way in rc.init), and the one with the double hash mark will _change_ the default setting to the opposite setting if uncommented. The rc.custom file is terribly consistant in this regard...read through it carefully and you'll see what I mean. Also, in this case, note that the default file contains _specific_ instructions on how to set this flag properly...it doesn't say uncomment the line above, but "this line" to restrict submissions. "This line," the one with the double hash marks, clearly unsets the variable (making it dissapear from the environment as if it never existed), and doesn't set it to "no" or "uh-huh" or any other value. (It doesn't even set it to a null value...it makes it dissapear in a flash of smoke.) Although I'd agree that some of the more esoteric settings in rc.custom might be a little confusing, this one is in my humble opinion TERRIBLY straight-forward, excellently notated, and should only cause confusion for those people who decide not to read the comments clearly typed out therein. It _does_ occasionally cause confusion, but I think Philip would be hard-pressed to make it any clearer. Charlie _______________________________________________ Smartlist mailing list Smartlist@lists.RWTH-Aachen.DE http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
Ok..now, and yes I am asking way tooo many questions..this is how I learn.Do I when I uncomment say.. #foreign_submit do i then recomment foreign_submit = yes...or just uncomment the new value and leave the old one uncommented. Thanks Jerry ps sorry for top posting -----Original Message----- From: smartlist-admin@lists.RWTH-Aachen.DE [mailto:smartlist-admin@lists.RWTH-Aachen.DE]On Behalf Of Charlie Summers Sent: Wednesday, December 27, 2000 6:08 PM To: Roger Burton West; SmartList-list Subject: Re: need help At 4:46 PM -0500 12/27/00, Roger Burton West is rumored to have typed:
That's because "foreign_submit = yes" means "allow foreign submission". Try "foreign_submit = no".
It'll work (if I remember, the code looks for "y" in the variable), but it makes a lot more sense to unset the variable as instructed in your default rc.custom.
And don't worry - many people find the syntax unclear.
Er...they do? If foreign_submit=yes, submissions from foreign addresses (those not subscribed) are accepted...foreign submissions...foreign_submit, get it? Seems pretty darned clear to me, anyway...especially if you actually read the comments listed in the rc.custom file.
What's commented out is in fact the default state, provided for your reference - if you want something other than the default, you have to put it in yourself.
Actually, that's not correct at all, since _both_ states are clearly in the rc.custom file. The default rc.custom file will have _two_ examples for most flags (yes/no settings), with different comment structures for the lines, as in (using the foreign_submit as an example): #foreign_submit = yes ##foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list Note that the first one has a single hash mark (#) denoting the comment, and the second line has a double hash mark. This means simply (and throughout the rc.custom file) that the one with the single hash mark is the pre-set default (set this way in rc.init), and the one with the double hash mark will _change_ the default setting to the opposite setting if uncommented. The rc.custom file is terribly consistant in this regard...read through it carefully and you'll see what I mean. Also, in this case, note that the default file contains _specific_ instructions on how to set this flag properly...it doesn't say uncomment the line above, but "this line" to restrict submissions. "This line," the one with the double hash marks, clearly unsets the variable (making it dissapear from the environment as if it never existed), and doesn't set it to "no" or "uh-huh" or any other value. (It doesn't even set it to a null value...it makes it dissapear in a flash of smoke.) Although I'd agree that some of the more esoteric settings in rc.custom might be a little confusing, this one is in my humble opinion TERRIBLY straight-forward, excellently notated, and should only cause confusion for those people who decide not to read the comments clearly typed out therein. It _does_ occasionally cause confusion, but I think Philip would be hard-pressed to make it any clearer. Charlie _______________________________________________ Smartlist mailing list Smartlist@lists.RWTH-Aachen.DE http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
At 8:28 PM -0500 12/27/00, Jerry Sloan is rumored to have typed:
Ok..now, and yes I am asking way tooo many questions..
Nope, you're not. You're nowhere _near_ that point yet.
this is how I learn.
Works for me...answering questions is how we teach.
Do I when I uncomment say.. #foreign_submit do i then recomment foreign_submit = yes...or just uncomment the new value and leave the old one uncommented.
Remember that if you uncomment the line that is single-hashed, it makes no difference, since the single-hashed commented line shows you what the default in rc.init is. So if that is what you want, you can leave things alone (_both_ lines commented), since it's already set that way. If you want to _change_ the flag, you would uncomment the double-hashed lines, like: #foreign_submit = yes foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list In almost no case wuold you want to uncomment the single-hashed line, since it would be redundant. (If you uncommented both in this example, the foreign_submit variable, which contains the value of "yes," would be re-assigned the value of "yes" then IMMEDIATELY sent into the great unknown by the next line. Note you would get what you wanted, but it wouldn't make a lot of sense to re-assign the same value again before making it dissapear.) Since you've already uncommented the first line, it would make sense to comment it again, using a single hash (to remind you that it is indeed the rc.init default). In the event you have something else and can't _remember_ teh default value, remember that there is an "untouched" copy of rc.custom in the .etc/ directory which you can review to remind yourself what was originally the default. (Just be careful not to change the .etc/rc.custom unless you know _exactly_ what you're doing...) Charlie P.S. This double-line thing doesn't apply to those non-flag variables which contain values...they generally are commented out with the default value in place. If you want to change, say, maxhist to 64 where it defaults to 32, you'd change the numeric value and uncomment the line. And some like unsub_assist are kinda hinky...they can contain a numeric value if they exist, but can also act like a flag and _not_ exist. I have to admit that wouldn't have been something I would have done, but it works, and isn't really confusing, so there are generally no complaints about it. Me
Well, my next question is this...if someone not in accept list sends mail to list address, and if I have rc.custom configured correctly, will that e-mail be posted to the list. The reason is that I have been sending mail to my list from addresses not in accept, and they are being posted to the list. Smartlist mailing list Smartlist@lists.RWTH-Aachen.DE http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
At 10:11 AM -0500 12/28/00, Jerry Sloan is rumored to have typed:
Well, my next question is this...if someone not in accept list sends mail to list address, and if I have rc.custom configured correctly, will that e-mail be posted to the list. The reason is that I have been sending mail to my list from addresses not in accept, and they are being posted to the list.
Nope; only messages coming from someone on the accept list will be accepted by SmartList once foreign_submit is unset. And I'm betting you're wrong, and they are _not_ being posted to the list. As list maintaiuner, though, you get a copy. Check the messages you're seeing for an X-Diagnostic: header field. Charlie ---------------------------------------------------------------------- L.O.F. Communications sales@lofcom.com The Katester and Santa: http://www.lofcom.com/personal/art/santa_2000_low.jpg
On Wed, Dec 27, 2000 at 06:08:29PM -0500, Charlie Summers wrote:
At 4:46 PM -0500 12/27/00, Roger Burton West is rumored to have typed:
And don't worry - many people find the syntax unclear. Er...they do? If foreign_submit=yes, submissions from foreign addresses (those not subscribed) are accepted...foreign submissions...foreign_submit, get it? Seems pretty darned clear to me, anyway...especially if you actually read the comments listed in the rc.custom file.
Sorry; what I mean is that the single- and double-commenting style seems to confuse people. It made perfect sense to me when I met it, but it does seem to have been one of the commoner causes of questions here. I agree that, if people read the comments in full, the style makes sense. But having the default setting commented out is, to my mind, counterintuitive. Roger
Roger wrote:
Sorry; what I mean is that the single- and double-commenting style seems to confuse people. It made perfect sense to me when I met it, but it does seem to have been one of the commoner causes of questions here.
I agree that, if people read the comments in full, the style makes sense. But having the default setting commented out is, to my mind, counterintuitive.
That I agree with... maybe a note at the top of the rc.custom file that states the commenting convention would help. On the other hand it is well commented on in the various FAQs. Sincerely, Joyce Miletic ******************
Roger wrote:
Sorry; what I mean is that the single- and double-commenting style seems to confuse people. It made perfect sense to me when I met it, but it does seem to have been one of the commoner causes of questions here.
I agree that, if people read the comments in full, the style makes sense. But having the default setting commented out is, to my mind, counterintuitive.
That I agree with... maybe a note at the top of the rc.custom file that states the commenting convention would help. On the other hand it is well commented on in the various FAQs. Sincerely, Joyce Miletic ******************
At 5:12 AM -0500 12/28/00, Roger Burton West is rumored to have typed:
I agree that, if people read the comments in full, the style makes sense. But having the default setting commented out is, to my mind, counterintuitive.
Possibly...but then the alternatives are either 1) not having the defaut setting at all in the rc.custom, or 2) re-setting all the values all over again, which is (IMHO) a real waste of computer cycles. Charlie
participants (5)
-
Charlie Summers -
Jerry Sloan -
Joyce Miletic -
Joyce Miletic -
Roger Burton West