I just started having trouble with my SmartLists - not sure what happened. Today, when I go to post from now the ONLY address in the accept file, it does not go out, and forwards the post to the maintainer with the message "X-Diagnostic - Not on accept list"
But it is!
Has anyone seen this before - I must maintain this as a very restricted list, as 1900 members get very teed off when anyone says hi to anyone else on the list....
Here is an update from today - after having established a new list, I used it to send out a message (actually one apologizing fofr any confusion and that I had recompiled the list and it was working normally again). I received about ten replies to the message which were handled appropriately, but then one from a compuserve account that once again bypassed the accept file, and went out to the whole list. Talk about having a red face....
The "foreign_submit = yes" line is uncommented in both the rc.init and the rc.custom
Does anyone have any ideas?
Bruce
At 4:17 PM -0500 12/6/01, williamsb@afip.osd.mil is rumored to have typed:
The "foreign_submit = yes" line is uncommented in both the rc.init and the rc.custom
Er...huh? Let's look at the way the foreign_submit variable is listed in rc.custom by default:
#foreign_submit = yes ##foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list
That means that the default value in rc.init for foreign_submit is "yes" and THAT means that addresses NOT in the accept file are allowed to post. (Default settings from rc.init are commented with one hash, _changes_ to the default are commented with two hashes. It ain't intuitive, but once you know it, reading rc.custom becomes _really_ easy.)
So you've repeted the setting from rc.init, which appears to be exactly the OPPOSITE of what you really want.
I would suggest that the first thing you do is set your rc.custom file to look like:
#foreign_submit = yes foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list
That will UNSET the foreign_submit variable (making it go *poof* and vanishing in a cloud of electrons), telling SmartList that you do NOT want anyone else except those addresses in the accept file to post.
Truth is, if you _really_ have foreign_submit containing "yes," it's a miracle that _every_ post sent to the list address didn't get distributed.
That said, simply using accept isn't very secure, since anyone can munge a header field and make it look like it's coming from your address anyway. If this is a broadcast-only list as it appears to be, where only you or a few trusted people are allowed to post, I'd urge you to make the list moderated and be done with it. Approve the messages you send to the list, and since other messages aren't approved, they _can't_ be distributed. (And if you want additional security, there are other moderation packages out there that allow for more security than is built into SmartList, and remember to remove the Approved: header field in rc.local.s20 before the mail is sent. I hacked a quick one a long time ago that forces the approval in the subject instead of a seperate header field, but there are much better things sitting around out there now.)
Charlie
On Friday 07 December 2001 05:48, Charlie Summers wrote:
Er...huh? Let's look at the way the foreign_submit variable is listed in rc.custom by default:
#foreign_submit = yes ##foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list
This is counter intuitive though. I know what it says and all that, but it easily leads you to assume that the "uncomment this line" part refers to the line just before it. I feel this section should either read:
#foreign_submit = no ##foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list
*or*
#foreign_submit = yes # uncomment this line if you # want to allow submissions of # people not on the accept list
My 2 cents worth.
Kind regards,
Remmy
At 12:11 AM -0500 12/7/01, Remco Rijnders is rumored to have typed:
This is counter intuitive though. I know what it says and all that, but it easily leads you to assume that the "uncomment this line" part refers to the line just before it.
It says pretty clearly to uncomment THIS line, not the line before it.
I don't argue at all that the system used to denote rc.init defaults (single-hash on default, double-hash on change) is a little odd, but you can't really extend that to saying that this specific descriptive text example, which says "Uncomment this line..." is somehow non-intuitive. You don't have to intuit _anything_ in that description, it's _telling_ you what it means.
(I also understand your need to asign a negative to foreign_submit; the idea of making a variable dissapear from the universe can be...unsettling. But if memory serves, and it usually doesn't, some tests are for value, others test for existance, so unsetting procmail variables has become the "standard" for SmartList - if it doesn't exist, it can't start with "y" and all that. You'll get no argument from me that it's a little different, but it's the way of things.)
Charlie
Remco Rijnders remco@webconquest.com schrieb:
#foreign_submit = yes ##foreign_submit # uncomment this line if you # want to restrict submitting to # people on the accept list
This is counter intuitive though. I know what it says and all that, but it easily leads you to assume that the "uncomment this line" part refers to the line just before it. I feel this section should either read:
#foreign_submit = no
That's the way many people think because most script languages and configuration files for such languages uses the syntax
variable [ = ] value
With procmail you can drop the equal sign to set a variable to an empty value and you don't need to care about whitespaces around this sign. That's convenient but odd and misleading.
I would suggest to rewrite the config files of smartlist (at least rc.custom) the way
var1 = value var2 = # this variable is empty or "not yes" # if var2 is boolean (yes or no) the value could # also be "no" or "foobar"
I think smartlist config files with this syntax would be easier to read for people not familiar with procmail and would avoid questions like above, coming up since smartlist has been released.
Werner
At 8:59 AM -0500 12/7/01, Werner Reisberger is rumored to have typed:
I think smartlist config files with this syntax would be easier to read for people not familiar with procmail and would avoid questions like above, coming up since smartlist has been released.
I'm thinking it would be easier and take less rewriting just to have an example at the top of the rc.custom file that explains it; something like:
#variable = value # One hash describes the stock rc.init default ##variable # Two hashes describe the CHANGE to the default
Not that _anything_ would help much, since there's no way the hosting providers who are supplying SmartList to their customers and then cutting them loose to fend for themselves would bother to upgrade anyway. I'm not sure some of them aren't still using 3.11pre5 now...(*sigh*)
Charlie
smartlist@lists.rwth-aachen.de
-
Charlie Summers -
Remco Rijnders -
Werner Reisberger -
williamsb＠afip.osd.mil